[Tutorial] Sauber Programmieren

  • Hallo,
    Auch ich finde dass dieses Tutorial sehr gut gestaltet ist!
    Nur halte ich mich meist auch nicht an diese "Regeln" des Codings, im Gegenteil.
    Da ich neu hier bin, habe ich mal eine Frage:
    Ist es wirklich so, dass wenn ich hier UDFS oder nützliche Skripts(Ich hätte welche, eins auf jeden Fall) präsentieren möchte, ich dazu verpflichtet bin, diesen Standardstiel zu verwenden?
    Mfg,
    gamefighter

    • Offizieller Beitrag
    Zitat von gamefighter

    Ist es wirklich so, dass wenn ich hier UDFS oder nützliche Skripts(Ich hätte welche, eins auf jeden Fall) präsentieren möchte, ich dazu verpflichtet bin, diesen Standardstiel zu verwenden?


    Nein, bist du nicht.
    Der Standardstiehl wird nur vorausgesetzt wenn du willst, das deine UDF, in die Autoit UDF einfließt.
    Aber da bist du eh im falschen Forum. Dafür ist das En-Forum zuständig.

    • Offizieller Beitrag

    Ist es wirklich so, dass wenn ich hier UDFS oder nützliche Skripts(Ich hätte welche, eins auf jeden Fall) präsentieren möchte, ich dazu verpflichtet bin, diesen Standardstiel zu verwenden?

    Nein, wenn du UDF erstellst und meinst diese sollten in die AutoIt-Includes übernommen werden, dann hast du dich an die Vorgaben zu halten, die du genau auf autoitscript.com nachlesen kannst.
    Für das Posten hier besteht keine Pflicht zur Notation. Wichtig ist, dass der Code in sich schlüssig und für jeden nachvollziehbar ist.

  • Ich habe hier noch etwas aus dem Core Language Tutorial. Habe ich auch oft falsch gemacht und oft falsch gesehen:

    [autoit]

    Local $aTest[5] = [1,2,3,4,5]
    Local $iSumme = 0

    [/autoit][autoit][/autoit][autoit]

    ; For $i = 0 To UBound($aTest)-1
    ; $iSumme += $aTest[$i]
    ; Next

    [/autoit][autoit][/autoit][autoit]

    ; RICHTIG (übersichtlicher und sprachlich logischer)
    For $i In $aTest
    $iSumme += $i
    Next

    [/autoit][autoit][/autoit][autoit][/autoit][autoit]

    MsgBox(0,"",$iSumme)

    [/autoit]

    Mal schauen wie sich das alles in der nächsten Stable ändert (mit eigenen "Typen" usw.)

  • Es gibt unheimlich (un-un-unheimlich) viele zu behebende Bugs, die durch die neuen Funktionen enstanden sind. Daher werden wohl noch einige Bugfixes und Reperaturen nötig sein. Es sind ja jetzt schon fast 10 neue Betas, und mindestens genauso viele wird es glaube ich noch brauchen ^^

    • Offizieller Beitrag

    Ich habe hier noch etwas aus dem Core Language Tutorial. Habe ich auch oft falsch gemacht und oft falsch gesehen:


    Das hast du m.M. weder falsch gemacht, noch falsch gesehen. Beide Varianten ( For-To / For-In ) sind legitim und auch richtig. "Richtiger" geht bekanntlich nicht :D
    Hier muß man auf den speziellen Einsatz schauen, welche Variante ggf. vorteilhafter sein kann. Die Unterschiede werden wohl vergleichbar sein wie bei: "$i = $i + 1" und "$i += 1" ;)

  • Ich sehe das auch etwas anders.

    Mit For ... in kann man eigentlich nur in einem Einzelfall durch ein Array loopen.
    Wüsste nicht wieso man dafür jetzt seinen Stil ändern sollte.

    For ... in verwendet ich daher eigentlich nur bei Objekten.

  • Ich nutze grundsätzlich For To.
    - Ne ganze Ecke schneller als For In
    - Man braucht den UBound sowieso oft in der Schleife, daher vorher berechnen und als Parameter übergeben.
    - Step funktioniert nicht

    Und ich finde es übersichtlicher.
    Aber das ist natürlich Geschmackssache.

    Wo ihr grade von der Beta sprecht.
    Wo kann man die "aktuelle" denn bekommen ?
    Alles was ich finde ist die Version vom April 2012.

  • Das IST die neuste. Meine Vermutung: So viele neue Funktionen, dass es eine Meng e Bugixes geben muss, bis die nächste kommt. Hinzukommen wird wohl nichts mehr.

  • Ich bevorzuge immer wenn es geht For .. In ..., denn:

    • Keine Off-By-one Errors und sonstige Zugriffsverletzungen
    • Man kann Elemente nicht versehentlich überschreiben
    • Der Sinn ist leichter ersichtlich


    - Ne ganze Ecke schneller als For In
    - Man braucht den UBound sowieso oft in der Schleife, daher vorher berechnen und als Parameter übergeben.


    Ich habe es gerade nachgemessen und keinen Geschwindigkeitsvorteil gefunden und UBound brauche ich oft auch nur ein einziges Mal pro Schleife.

    Allgemein bevorzuge ich in Programmiersprachen sogar, wenn nur foreach-Schleifen vorhanden sind und man dafür

    Code
    for i in range(start, end, step) schreibt

    So ist das in Python und das finde ich sehr übersichtlich, weil es so konsequent ist, und man in anderen Sprachen oft viel mehr Objekte als nur Arrays hat.

  • Der Geschwindigkeitsunterschied ergibt sich wenn die Einzelelemente größer werden.
    Hier z.B. mal mit Strings als Arrayelemente:

    Spoiler anzeigen
    [autoit]

    Global Const $N = 1e5
    Global Const $S = 50

    [/autoit] [autoit][/autoit] [autoit]

    Global $iT, $i, $x

    [/autoit] [autoit][/autoit] [autoit]

    Global Const $s_String = BinaryToString(InetRead("http://www.google.de", 1))
    Global $a_Test[$S+1]

    [/autoit] [autoit][/autoit] [autoit]

    ; Array erstellen:
    For $i = 0 To $S
    $a_Test[$i] = $s_String
    Next

    [/autoit] [autoit][/autoit] [autoit][/autoit] [autoit]

    ; For-To mit jeweils immer Ubound als Obergrenze
    $iT = TimerInit()
    For $x = 1 To $N
    For $i = 0 To UBound($a_Test) - 1
    Next
    Next
    $iT = TimerDiff($iT) / $N
    ConsoleWrite(StringFormat("For-To Ubound:\t%8.4f ms\n", $iT))

    [/autoit] [autoit][/autoit] [autoit]

    ; For To mit schon bekannter Obergrenze
    $iT = TimerInit()
    For $x = 1 To $N
    For $i = 0 To $S
    Next
    Next
    $iT = TimerDiff($iT) / $N
    ConsoleWrite(StringFormat("For-To fest:\t%8.4f ms\n", $iT))

    [/autoit] [autoit][/autoit] [autoit]

    ; For-In
    $iT = TimerInit()
    For $x = 1 To $N
    For $i In $a_Test
    Next
    Next
    $iT = TimerDiff($iT) / $N
    ConsoleWrite(StringFormat("For-In:\t\t%8.4f ms\n", $iT))

    [/autoit]

    Der Grund hierfür ist, dass die For-In-Schleife für jeden Schleifendurchgang ein Kopie des derzeitigen Elementes erstellt mit dem dann gearbeitet wird.
    Wenn man also z.B. For $i In schreibt ist $i nicht das jeweilige Element sondern lediglich eine Kopie.
    Das erklärt auch das schreibgeschützte Verhalten.
    Im realen Einsatz ist dieser Unterschied wohl aber ziemlich irrelevant und eher von der jeweiligen Verwendung innerhalb der Schleife abhängig.

    Prinzipiell sehe ich das ähnlich wie Marthog.
    Wenn man es nutzen kann ist For In für mich übersichtlicher da man in der Schleife nicht mit Array-Indizes arbeiten muss.
    Sicherer ist es zudem auch.
    Leider sind viele von Autoit-Funktionen derart dämlich aufgebaut (Anzahl der Elemente im ersten Element), dass man For-In hierfür nicht anwenden kann.

    Zu irgendeinem der beiden raten würde ich nicht.
    Kann jeder selbst entscheiden was für ihn in welcher Situation besser ist.

  • Vielen Dank für das Tutorial!
    Mir ist noch etwas aufgefallen: Und zwar würde ich wichtige Optionen, die für das ganze Skript gelten, auch oben hinschreiben. Dazu zähle ich z.B.
    [url='http://translation.autoit.de/onlinehilfe/functions/Opt.htm']

    [autoit]

    Opt("MustDeclareVars", 1)

    [/autoit]

    und Optionen die das Koordinatensystem beeinflussen etc.

  • Die Farben der Überschriften auf jeden Fall eins dunkler, auf Echtfarben- bzw. Adobe RGB Monitoren sieht man fast nichts mehr. Die Kennzeichnung mit Farben sieht auch eher extrem unaufgeräumt auf. Wichtig ist doch eine sinnvolle (selbstgewählte) Unterteilung mit Überschriften in verschiedenen Größen und Breiten.

    2 Mal editiert, zuletzt von minx (11. Januar 2013 um 16:34)

  • Ich habe einfach mal auf gut Glück "red", "green" & "blue" benutzt. Habe mir schon gedacht, dass da nicht so viel Gutes bei rum kommen kann. :pinch:
    Oder... Welche Überschriften meinst du eigentlich? Ich meinte die in dem Changelog-Beispiel.

    Und natürlich selbstgewählt, das war ja auch nur ein Beispiel. ;)

    chess

  • //
    Die 3-teilige Sache bringt eigentlich projektspezifisch auch nichts. Meine Meinung wäre: Kurze Einleitung worum es geht, und darauf ein grammatikalisch und rechtschreibmäßig, sowie optisch annehmbar formatierter eigener Text zum Programm. Änderungen sollten nicht mit einem Change-log im Startpost gekennzeichnet werden, dazu sollte man das Skript lieber zippen und eine README sowie CHANGELOG und vlt. TODO Datei hinzufügen. Wenn ein Skript aktualisiert wird, so sollte die neue Änderung stets als neuer Post im Thema erwähnt werden, zum Ersten kann man so die chronografische Entwicklung des Skripts verfolgen und zum Zweiten wird das Thema damit automatisch gepusht, was auch andere auf das Skript hinweist. natürlich darf man dies nicht übertreiben.