Zeilen tauschen und hinzufügen

  • Ich habe dir zugestimmt, dass es schon sehr große Arrays sein müssen, bevor das auffällt.

    Die Arraygröße spielt keine Rolle, UBound wird nur einmal berechnet, ich kriege für riesige und kleine Arrays den selben Zeitaufwand.

    Die Zeit den Wert abzurufen ist zwar doppelt so groß, verglichen mit dem Abspeichern in eine Variable, aber wie bereits erwähnt ist das vernachlässigbar gering.

    Wir bewegens uns (bei meinen Resultaten jetzt) bei 600.000 UBounds (drei Dimensionen) pro Sekunde, das sind ~0.5µs pro UBound, das ist nichts (in AutoIt-Maßstäben!!).

    Bei solchen Zeiteinheiten sollte es, meiner Meinung nach, viel eher um die Gestaltung und den Stil des Codes gehen als noch das letzte bisschen Performance rauszuholen,

    da diese in 99.999% der Skripte schlicht nicht benötigt wird, und wenn doch dann AutoIt nicht das Mittel der Wahl ist sondern man lieber ASM oder DllCalls nutzen sollte.

    Ich habe schon in Skripten innerhalb von Schleifen UBound verwendet, obwohl ich die Größe, für das ReDim davor, bereits errechnet habe und UBound den selben Wert liefern wird.

    Warum? Es sieht konsequenter aus und man muss nicht erst hochscrollen um zu wissen was da steht. Für mich ist der obere Code wesentlich besser als der untere, aber das muss jeder für sich entscheiden.

    Jeder hat schließlich seinen eigenen Stil.

    Code
    $iSecondDim = 1337
    ReDim $aMyArray[UBound($aMyArray)][$iSecondDim][UBound($aMyArray, 3)]
    
    For $i = 0 To UBound($aMyArray) - 1
        For $j = 0 To UBound($aMyArray, 2) - 1
            For $k = 0 To UBound($aMyArray, 3) - 1
                ;...
            Next
        Next
    Next
    Code
    $iSecondDim = 1337
    ReDim $aMyArray[UBound($aMyArray)][$iSecondDim][UBound($aMyArray, 3)]
    
    For $i = 0 To UBound($aMyArray) - 1
        For $j = 0 To $iSecondDim - 1
            For $k = 0 To UBound($aMyArray, 3) - 1
                ;...
            Next
        Next
    Next
  • Bei solchen Zeiteinheiten sollte es, meiner Meinung nach, viel eher um die Gestaltung und den Stil des Codes gehen als noch das letzte bisschen Performance rauszuholen,

    Genau darum geht es doch!

    GESTALTUNG und STIL eines Codes haben essenziell mit der Wartbarkeit zu tun! Man schreibt doch nicht einen NICHT (gut) debugbaren Code, nur weil er "schön" aussieht?!

    Oder heißt das etwa, man schreibt erst einen gut debugbaren Code, und macht ihn dann, wenn er fehlerfrei läuft, "schön"?

    Zeit (im Sinne von Scriptlaufzeit) ist imho auch völlig überbewertet, jedenfalls bei vorliegendem Problem.

    //OT-Modus ON

    Wobei ich mal gerne einen Vergleich mit Texten >500.000 Zeilen sehen würde. Da ist die Stringfunktions-Variante wahrscheinlich mit dem "fertige Datei schreiben" schon fertig, bevor das FileReadToArray() durch ist....

    Vom Regex ganz zu schweigen.

    //OT-Modus OFF

    Ich jedenfalls würde folgende Variante vorziehen. Jede Variable ist per ALT-D oder STRG+SHIFT+D abzufragen.

    Gefühlte 99% aller "Mein Script/Programm funktioniert nicht!"-Posts in sämtlichen Programmiersprachenforen haben GENAU DIESES Thema als Ursache!

    Der Programmierer geht davon aus, das das Programm das tut, was er sich VORSTELLT, was es denn tun soll. Aber Überprüfung?! Fehlanzeige!

    Wie kommen denn diese Posts zu einem befriedigenden Ergebnis, aka "fehlerfreiem Programm"?

    Gucken irgendwelche mit dem "göttlichen Blick" behafteten Hacker auf den Code und "sehen" den/die Fehler? Sicher nicht.

    Die setzen Breakpoints und überprüfen Werte, und bauen so nebenbei (wenn sinnvoll und erforderlich) ein "Errormanagement" auf.

    Der Fehler wird lokalisiert und ausgemerzt. Denn gefunden wurde er mittels debugging, und das macht absolut keinen Spass, wenn der Code dafür nicht vorbereitet ist.

    Es sieht konsequenter aus und man muss nicht erst hochscrollen um zu wissen was da steht

    Wenn die Anzahl Buchstaben des Funktionsnamens/Parameter übersichtlich ist, warum nicht, aber idR machst du das so

    Code
    Local $tGM = _WinAPI_GetGlyphOutline($hDC, ChrW(77), $GGO_BITMAP, $pData)
    Local $W = DllStructGetData($tGM, 'BlackBoxX')
    Local $H = DllStructGetData($tGM, 'BlackBoxY')
    Local $SIZE = $W * $H
    
    und nicht so
    
    Local $SIZE = DllStructGetData(_WinAPI_GetGlyphOutline($hDC, ChrW(77), $GGO_BITMAP, $pData), 'BlackBoxX') * DllStructGetData(_WinAPI_GetGlyphOutline($hDC, ChrW(77), $GGO_BITMAP, $pData), 'BlackBoxY')
  • Genau darum geht es doch!

    GESTALTUNG und STIL eines Codes haben essenziell mit der Wartbarkeit zu tun! Man schreibt doch nicht einen NICHT (gut) debugbaren Code, nur weil er "schön" aussieht?!

    Oder heißt das etwa, man schreibt erst einen gut debugbaren Code, und macht ihn dann, wenn er fehlerfrei läuft, "schön"?

    Hast es auf den Punkt gebracht. :thumbup:

    Die UBound-Abfrage ist sowieso redundant gewesen, im For-Header hätte man direkt auf -2 setzen können (hatte ich ja geschrieben), das wäre auch optisch mMn. schönerer Code geworden.

    Ich jedenfalls würde folgende Variante vorziehen. Jede Variable ist per ALT-D oder STRG+SHIFT+D abzufragen.

    Hier unterscheiden sich die Geschmäcker weil es keinen wirklichen IDE-Debugger wie bei Visual Studio oder ähnliches gibt. (Zumindest nicht in der Standardinstallation).

    Ich nutze viele ConsoleWrites und lass mir immer an den Stellen die Werte ausgeben die ich überprüfen will und sichere nicht beim Coden extra alles explizit in eine Variable, nur die Sachen die ich überprüfen möchte.

    Ich versuche einfach konsequent sauber zu coden und stilsicher zu bleiben ohne dabei Einschränkungen in Hinsichten von Wartung, Lesbarkeit hinzunehmen.

    Das klappt auch ganz gut, da ich sehr schnell Fehler finde indem ich kurz auf den Code schaue, da brauch ich nicht viele Debugsprints.

    Bei dem DllStruct Beispiel ist es natürlich klar, hier sollte man die Variablen als Mittel zum Zweck sehen und nicht als Datencontainer verwenden, sondern viel mehr als "Alias".

    ___

    Es ist überraschen wie viel spaßiger Programmieren sein kann, wenn man einfach mal konsequent sich bemüht guten Code zu schreiben.

    Da macht das Lesen Spaß, Debuggen Spaß, einfach alles. Neue Probleme kann man rasend schnell lösen und nach Wochen lässt sich nach ein paar Blicken auf den Code wieder alles erkennen.

    Das soll jetzt aber nicht heißen, dass man nicht auch "schlechten" Code schreiben kann, wenn man kurz was testen will kann man auch gerne Stilsicherheit etc. völlig links liegen lassen,

    solange man hinterher aufräumt und wieder gut weitermacht.

    ___

    Der Thread ist zwar jetzt komplett entgleist aber solche Diskussionsperlen entstehen spontan :)

  • Der Thread ist zwar jetzt komplett entgleist aber solche Diskussionsperlen entstehen spontan

    Vielen Dank für Eure rege Teilnahme :)

    Es ist überraschen wie viel spaßiger Programmieren sein kann, wenn man einfach mal konsequent sich bemüht guten Code zu schreiben.

    Welcher Code ist aus Eurer fachlichen Meinung die beste Umsetzung zur Fragestellung = "guten Code" laut alpines Zitat?

    Einmal editiert, zuletzt von AutoMit (22. September 2018 um 16:56)

  • Jede Variable ist per ALT-D oder STRG+SHIFT+D abzufragen.

    In welchem Programm funktioniert das?


    Hier unterscheiden sich die Geschmäcker weil es keinen wirklichen IDE-Debugger wie bei Visual Studio oder ähnliches gibt. (Zumindest nicht in der Standardinstallation).

    Welchen Debugger gibt es in der "nicht Standardinstallation" ?


    Grüner Haken gesetzt – vielen Dank für die sehr interessanten Anregungen :)

    Versuche noch die Regex Variante zu verstehen, die Array Variante von Bitnugger konnte ich auf meine Strings anpassen.

  • Welchen Debugger gibt es in der "nicht Standardinstallation" ?

    AU3Check - bzw. Au3Check.exe, bei der installierten Version normal zu finden in: C:\Program Files (x86)\AutoIt3\

    Ein echter Debugger ist das aber nicht... wie der Name schon sagt, ein Programm, dass das Script vorab auf Syntaxfehler prüft...

    "nicht Standardinstallation" ...die Default-Installation würde ich eher als Minimal-Installation bezeichnen... und mit SciTE4AutoIt3 als erweiterte Installation.

    Einmal editiert, zuletzt von Bitnugger (22. September 2018 um 22:12)

  • AU3Check - bzw. Au3Check.exe, bei der installierten Version normal zu finden in: C:\Program Files (x86)\AutoIt3\

    Wie du schon sagtest ist das kein Debugger. Au3Check prüft glaube ich nur ob die Programme syntaktisch soweit in Ordnung sind.

    Die Fehlermeldungen (Out of Bounds, etc) kommen vom Interpreter.

    Einen Debugger wie bei VS wo man bestimmte Variablen pinnen kann, CPU-Last, RAM-Verbrauch überwachen und sonst welchen Schabernack machen kann gibts von offizieller Seite aus nicht, und wird vermutlich auch nie kommen.

    Es gibt inoffizielle Sachen wie AutoIt Debugger und das was ISI verbaut hat, mehr fällt mir nicht ein. Aber autoBert hat da ja ein paar verlinkt.

    In welchem Programm funktioniert das?

    In SciTE mit SciTE4AutoIt.exe, geh mal in den Reiter "Tools" da findest du unten die beschriebenen Hotkeys.

    Welcher Code ist aus Eurer fachlichen Meinung die beste Umsetzung zur Fragestellung = "guten Code" laut alpines Zitat?

    Das If UBound in der Schleife kannst du bspw. komplett weglassen, da es semantisch keinen wirklich Mehrwert hat. Wenn man im For-Header -2 angibt, funktioniert das auch.

    Es gibt nicht >die< beste Lösung denn es hängt einfach vom Geschmack ab. Performancetechnisch werden sich die Implementationen so gut wie nichts nehmen.