Oder $p für Pfade lassen und $ptr für Pointer.
Aber es gibt noch mehr, wie zB. Structs!
Ich möchte für möglichst wenig das $v (Variant) verwenden.
Macht ihr nun nach dem Prefix ein Underscore? Bei $ptr wäre es vermutlich übersichtlicher!
Aber dann müsste man es überall haben....???
Die Anwendung von Notationen fördert durchaus die Lesbarkeit.
Ich habe mir inzwischen noch angewöhnt, Variablen die im Funktionskopf stehen in der Form $_Variable darzustellen. So ist innerhalb der Funktion schneller ersichtlich, welche Variable als Parameter übergeben wurde.
In einigen UDF findet man die Parametervariablen in Großbuchstaben. Das finde ich unpassend. Großbuchstaben sollten ausschließlich für Konstanten und Strukturen verwendet werden.
Vieles ist dabei natürlich Geschmackssache.
Aber, wie schon richtig gesagt wurde: Gut kommentiert, ist halb gelesen. 
Dir ist ein kleiner Fehler unterlaufen: Du verwendest die Variable $hGUI ohne vorherige Deklaration. Die Deklaration einer Variable, Konstante oder einem Array kann mit dem Schlüsselwort Dim, Global, Local oder Const gesehen. Eine Deklarierung kann auch erzwungen werden, indem man AutoItSetOption('MustDeclareVars', 1) an dem Skriptanfang schreibt. Alle unbekannten Variablen führen dann zu einer Fehlermeldung.
Die Konvention, jedes Wort im Variablennamen mit einen Großbuchstaben zu beginnt, heißt Pascal Case.
Finde Notationen irgendwie eine überflüssig Erfindung. Ist mehr eine Ausrede wenn man zu faul ist das ganze mit gescheiten Kommentaren zu versehen ;).
Finde Notationen irgendwie eine überflüssig Erfindung. Ist mehr eine Ausrede wenn man zu faul ist das ganze mit gescheiten Kommentaren zu versehen ;).
Ich finde Notationen praktisch, aber jeder hat seinen eigenen Stil. Vor allem in AutoIt geben ich gerne den Datentyp per Notation an, gerade weil ansonsten alles Typenlos ist.
Hilft auch bei der Autovervollständigung. 
In Konkurrenz zu Kommentaren sehe ich das eigentlich nicht.
$o_
;oder
$o
Verwende ich meistens für Objekte.
Bei einem strukturierten Script sollte man auf beides achten. Denn Notation und Kommentare zusammen sind auch ganz nützlich.
Die Notation (Womit hier wohl im allgemeinen das Variablenpräfix gemeint ist) gibt den Typ der Variable an, und der Kommentar dahinter den Sinn und Zweck, damit der Variablenname nicht zu lang wird.
So sehe ich das zumindest.;)
So, jetzt zu den Beiträgen im einzelnen:
BugFix Das mit den $_...-Variablen ist interessant. Mit deiner Erlaubnis würde ich das ebenfalls in das Tutorial als Optional übernehmen. Vielleicht bildet sich ja wirklich sowas wie ein Community-Standard... schlecht wärs auf jeden Fall nicht, wenn man jeden Code nach dem gleichen Prinzip lesen kann.
_mk_ Jup, aber theoretisch würde das Script auch ohne vorherige Deklaration laufen. Wie du bemerkt hast, achtet AutoIt (Im Gegensatz zu ein paar anderen Sprachen, wenn ich mich recht erinnere) nur dann auf die vorherige Deklaration, wenn AutoItSetOption('MustDeclareVars', 1) im Script steht. Dennoch gehört das eigentlich zum ordentlichen Programmieren dazu. Ich werde das dementsprechend abändern.
Und was das mit PascalCase angeht, das wusste ich auch noch nicht. 
chip Siehe das, was ich ganz am Anfang von dem Beitrag geschrieben habe.
@progandy Für die Übersichtlichkeit ist das wahrscheinlich eine der wichtigsten Sachen.^^
nuts Ja, stimmt, wenn man bei eingetipptem "$i" alle Int-Variablen angezeigt bekommt, hat das auch einen gewissen praktischen Wert.
Die Objekte, genau. Dann hätten wir genug zusammen, ich werde das heute oder morgen in den Startpost übernehmen, danke!
lg chess
Und was das mit PascalCase angeht, das wusste ich auch noch nicht.
Es ist eher CamelCase, da der Präfix mit einem Kleinbuchstaben anfängt. PascalCase beginnt immer mit einem Großbuchstaben. CamelCase ist außerdem der bekanntere Begriff.
Ach ja, nochmal zu den Präfixen. Da hat eben jeder seine eigene Variation der ungarischen Notation. Voll ausgeschrieben wäre bei mir dann so etwas: $g_UdfA_hGlobalHandleForUdfA oder $_tStruct oder $s_vStaticData
Noch eine Anmerkung:
[autoit]$p - Pfad
[/autoit]
Das ist ja ein String und den Inhalt einer Variable sollte man dann eher im eigentlichen Namen spezifizieren.
Wenn du schon sowas wie einen Comminuty-Standard herausarbeiten willst ist diese Notation zumindest diskussionsfähig. 
Die ungarische Notation führt, wie man hier erkennen kann, oft zu Missverständnisse. Der Präfix p wird einmal als Pfad verwendet, dann als Pointer benutzt oder er markiert eine Variable als Funktionsparameter. Deshalb sollte man auch auf den Gebrauch der ungarischen Notation verzichten.
Hinzu kommt das AutoIt ein schwach typisierte Sprache ist. Es gibt nur einen Datentypen, nämlich Variant. Dieser kann alle möglichen Arten von Daten aufnehmen. Während des Skriptablaufs kann dieselbe Variable unterschiedliche Datentypen speichern. Die Zuordnung der Variable zu den Subtypen(Fließkommazahl, Zeichenkette, Zeiger, etc.) findet nach dem aktuellen Inhalt statt.
Dadurch kommen wir zu einem weiteren Problem: implizierte Typenkonvertierung, die viele "unschöne" Anweisungen zu läßt. Leider wird die implizierte Datentypenkonvertierung von vielen Programmierer verwendet, anstatt die Werte explizit mit einer Umwandlungsfunktion(Int(), String()) zu konvertieren. Wenn man aber die implizierte Konvertierung gebraucht, sollte man für die Zeichenkettenverkettung das käufmannische Und(&) statt des Pluszeichens verwenden.
Beim dem Beispiel aus dem Tutorial, $IchBinEineVariable, handelt sich um die Pascal Case-Schreibweise.
Gutes Tutorial, auch der Tipp mit dem Einrücken bei GUI-Element Optionen gefällt mir sehr gut und macht den Code wirklich (auch für andere) viel besser lesbar.
Hey
Du sagst zwar was "Sauberkeit" für dich bedeutet, aber ich würde mal sagen Struktur ist ziemlich subjektiv. Es gibt wohl den ein oder anderen, der ByteCode einem ausführlichen, funktionalen und kommentierten Code vorzieht :D. Als praktisches Beispiel mag ich persönlich Einrückungen wie
$Form1 = GUICreate($sTitle, 300, 60)
GUISetBkColor(0x000000, $sTitle)
überhaupt nicht.
Außerdem glaube ich eher, dass du die Grundstruktur meinst, die zum allgemeinem Verständniss des Codes, falls man ihn teilen will/muss, für eine Sprache üblich ist. So etwas würde ich auch evt noch genauer dazuschreiben, damit wirklich jeder weiß, was in deinem Tut vorkommt.
Aber ansonsten: Gutes Tut
Um noch tiefer in Materie einzusteigen, solltest Du Dir verschiedene Programierstandards anschauen.
Hier haben sich bereits Programmierer Gedanken gemacht, wie man "sauber" programmiert:
Gutes Tutorial, auch der Tipp mit dem Einrücken bei GUI-Element Optionen gefällt mir sehr gut und macht den Code wirklich (auch für andere) viel besser lesbar.
Da siehst du mal, wie widersprüchlich das menschliche Empfindungen sind.
Derartige Einrückungen stören aus meiner Sicht die Lesart. Denn primär dienen Einrückungen dazu eine Substruktur anzuzeigen, was hier eindeutig nicht der Fall ist.
Ähnlich geht es mir mit Leerzeilen. Als ich mit VB anfing, stand in dem Lehrbuch, man möge nach jeder Codezeile eine Leerzeile einfügen. Dadurch wird aber schon ein 25-Zeilen Code auf 50 Zeilen aufgebläht - ohne Sinn und Verstand.
Leerzeilen machen Sinn, wenn man einen Codeblock markieren möchte, z.B. in der GUI die Deklaration von Groups und deren Inhalte, sodass auch codemäßig diese Gruppierung deutlich wird. Wobei man dazu auch sehr gut #region - #endregion nutzen kann.
Und bei großen Skripts eine große Hilfe, wenn die Erklärungen zu Variablen/Funktionen überall im Skript auslesbar sind (mit diesem Tool)
Bleibt als Resümee:
Eine Sprache wie AutoIt, die selbst kaum Konventionen vorgibt, wird immer von jedem anders behandelt werden.
Testet euch doch mal selbst: Öffnet ein (umfangreicheres) Skript, dass ihr vor >1 Jahr erstellt habt. Wißt ihr auf Anhieb wieder, was wo passiert? 
Wenn ja - Dann ist es sauber programmiert, egal welche Notationen verwendet wurden. 
chesstiger : Du hast gesagt, dass $n.. für Fließkommazahlen sind. Wieso nutzt du dann $nMsg für GUIGetMsg()? Da nehme ich dann $i... oder halt im Advanced-Modus $a...
Und für Hex nehme ich auch $i..., da Hex nur eine Darstellungsform ist. Für Boolean nehme ich nämlich $x...
Das hab ich so von der SPS-Programmierung mit übernommen.
Für Structs nehme ich $str...
Was soll eigentlich bei vielen UDF's $g... heißen?
Was soll eigentlich bei vielen UDF's $g... heißen?
g definiert den Sichtbarkeitbereich einer Variable und steht für global.
So, will ich mich auch mal wieder zu Wort melden, nachdem ich die Antwort etwas versäumt habe...
AntiSpeed & BugFix
Die Einrückung mit dem Tab ist tatsächlich etwas verwirrend. Vielleicht sollte hier auf ein Space zurückgegriffen werden:
$Form1 = GUICreate($sTitle, 300, 60)
GUISetBkColor(0x000000, $sTitle)
Man kann es immernoch deutlich im Code erkennen, jedoch auch deutlich von Tab-Einrückungen unterscheiden.
AntiSpeed
Natürlich ist diese Art der Ordnung subjektiv. Dennoch würden ein paar Standard-Richtlinien für den persönlichen sowie für den Community-Gebrauch nicht schaden. Standardisierter Code wäre für uns alle hier im Forum, besonders bei Hilfegesuchen, ein großer Segen.
@DaX
Guck ich mir morgen früh an (Schulfrei 
)!
Hört sich aufjedenfall interessant an.
BugFix
Wer hat sich denn den Müll in diesem VB-Buch ausgedacht? :o
Was #region angeht... Das habe ich total in dem Tutorial total vergessen. 
Muss ich unbedingt noch was zu schreiben, das ist ja auch sehr hilfreich.
Vor >1 Jahr... Naja, damals wusste ich noch nicht, was eine Funktion ist, also von daher...
Dürfte das wohl das reinste Chaos sein. 
@m-obi
Ich weiß auch nicht genau, wieso ich "n" davor setze. Das habe ich mal in einem Codeschnipsel gesehen, und hab das irgendwie geistlich übernommen - schlechte Angewohnheit.
Muss ich mir unbedingt mal abgewöhnen, werde das natürlich in dem Tutorial abändern - Muss in geistiger Abwesenheit in das Tut gekommen sein.
Ja, Hex ist nur eine Darstellungsform, aber ich bevorzuge das, damit ich zum Beispiel Farbcodes auf den ersten Blick erkenne:
[autoit]
$xColor = 0x0000FF
_mk_
Ja, m-obi's Frage beantwortet, werde ich auch aufnehmen in die Präfix-Liste.
lg chess
Edit:
Was solche Sachen wie $x angeht: Ich hatte das mit dem Primär- und Sekundär-Präfix schon ganz vergessen.
Ich persönlich würde daher folgendes Vorschlagen:
$<Datentyp><Sinntyp>
Mit Sinntyp ist so etwas wie ein Dateipfad oder eine Hexadezimalzahl gemeint, als Beispiel:
$spBeispiel1 = "C:\Windows\System32\cmd.exe"
$ixBeispiel2 = 0x0000FF
Bei $spBeispiel1 handelt es sich um eine Variable des primitiven Datentypes "s", also "String", und des Sinntypes "p", also "Path". Diese Variable enthält also einen String, der einen Dateipfad darstellt.
Bei $ixBeispiel2 handelt es sich um eine Variable des primitiven Datentypes "i", also "Integer", und des Sinntypes "x", also "Hexadecimal" ("Hex"). Diese Variable enthält also eine Ganzzahl in hexadezimaler Schreibweise.
Würde mich interessieren, was ihr von dieser Vorgehensweise haltet.
lg chess
