Funktionsnamen mit Unterstrich

Der wird verwendet um anzuzeigen, dass es sich um eine Funktion aus einer UDF handelt.

Zitat von mumpel

Na dann muss ich den nicht zwingend verwenden.

Nein, es gibt keine verpflichtenden Regeln, wie z. B. in Python.

Aber wenn man Scripte veröffentlicht ist es schon hilfreich, wenn für wesentliche Elemente möglichst einheitliche Formen gewählt werden. Das erleichtert auch Helfenden das Script zu lesen.

Ich mach es so, dann kann man am besten zwischen den Funktionen unterscheiden.

GuiCtrlCreateEdit(...) ; AutoIt-Funktion
__GuiCtrlEdit_Create(...) ; UDF-Funktion (mit AutoIt ausgeliefert)
_GuiCtrlCreateEdit(...) ; Eigene Funktion (um z.B. ein Edit zu erstellen und schon nen Font,... an einer einheitlichen Stelle zu setzen, wenn man mehrere Controls braucht)
__ExtendedEdit_GuiCtrlCreateEdit(...) ; Eigene UDF-Funktion (Wenn man selbst eine lib/UDF(user defined function) erstellt)

Man kann die Funktionen natürlich auch anders benennen, aber mit dieser Notation sieht man auf den ersten Blick, ob es sich um eine Grundfunktion handelt, eine eigene Funktion, oder ob die Funktion aus einer UDF stammt (und auch aus welcher).

Die UDF Notation nutze ich auch bei globalen Variablen in eine UDF, wenn ich eine erstelle. Z.b. Local $__ExtendedEdit_sEdit = 0. Dann hat man nicht das Problem, dass Konflikte mit den Namen entstehen und wenn man z.B. Konstanten verwendet weiß man auch direkt, aus welcher UDF die kommt.

Ich finde das z.B. bei den mitgelieferten UDFs teilweise nervig, weil die Konstanten das dort nicht haben und du dann oft erstmal rausfinden musst, aus welcher UDF denn jetzt die blöde Konstante kommt. Oft am schnellsten in dem man nach nem Script Beispiel schaut und dort alle includes nimmt und nacheinander ausprobiert/auskommentiert :/. Die wenigsten wissen direkt, ob z.B. $ES_RIGHT aus GUIConstants.au3, GUIConstantsEx.au3 oder WindowsConstants,... kommt. Aber das ist das Problem, das entsteht, wenn man sich nicht einheitlich Festlegt (man muss es ja nicht vom Compiler erzwingen, sollte es aber als gewollten Stil angeben...). Das selbe Problem gibts auch mit zurückgegebenen Arrays. Manche Funktionen geben beim ersten Index ([0]) die Anzahl der Ergebnisse zurück, andere geben keine Anzahl zurück... Ich persönlich bin der Meinung, dass es dafür Ubound gibt und man Programmierinfos und Daten trennen sollte, aber es wurde halt nie eindeutig definiert, also gibts jetzt nen Wildwuchs von beidem und man hat halt manchmal das Problem, dass komische Fehler auftreten, weil plötzlich son extra Wert immer Array steht, der da nicht hingehört...

Würde also empfehlen, das so zu handhaben, damit auch andere sich in deinem Code schneller zurechtfinden und direkt wissen, wo eine Funktion und deren Dokumentation denn zu finden ist.

Zitat von mumpel

Für mich ist der Unterstrich gewöhnungsbedürftig.

Ich gehe davon aus, dass die Gewöhnungszeit relativ kurz sein dürfte

Ich finde das mit dem Unterstrich besser.

Begründung:
Ich suche nach einer Funktion, weiß aber nicht genau wie ich sie genannt habe. Dann suche ich nach 'Func _' und dann F3 bis zur gesuchten Funktion.

Ich verwende das immer so:
MyFunc    -> Funktion die "klein" ist. z.B. Cosh, Sinh, Array, Map, MapContains, Print, StringToStruct, etc.
_MyFunc   -> Mittelgroße Funktionen, im Falle von UDFs: Diese Funktionen enthalten die Hauptfunktionalität
__MyFunc  -> ByRef Wrapper oder Internals.
___MyFunc -> ByRef Wrapper (andere Ausreden gibts nicht für 3 Layer :D)

Globale Variablen:
$ABC_MyVar, wobei ABC die Abkürzung für das Modul, oder die UDF ist. z.B. $A3D_PEN -> Teil von A3D, Enthält einen GDIPlus-Pen.

("große" Funktionen gibts bei mir nicht, weil ich üblicherweise alles zerteile, wenn es zu groß wird)

M

Es gibt viele Dinge, die hier individuell sehr unterschiedlich Anwendung finden. Ich beginne z.B. Parametervariablen in Funktionen (fast) immer mit $_. Somit weiß ich mit einem Blick, welche Variablen übergeben worden und welche aus der Funktion selbst stammen.

Aber wenn ein Code zumindest in sich einheitlich geschrieben ist, ist jede Variante völlig in Ordnung.

Zitat von mumpel

Nämlich sprechende Namen mit dem Kürzel des Typs davor (var für Variant, str für String, int für Integer, lng für Long, obj für Object etc. pp.). Z.B. $strEditbox1 = für den Inhalt der ersten Textbox.

Es gibt für AutoIt auch "best coding practices", die vorgeben, wie man am besten benennen sollte: https://www.autoitscript.com/wiki/Best_coding_practices

Deshalb wirst du in AutoIt eig. nur (v für Variant, s für String, i für Integer, o für Object etc. pp.) finden.

Ist aber zumindest ähnlich zu VBA.

Das wird in der Regel in AutoIt gerne mit einem Kleinbuchstaben gezeigt:

$sVariable = String
$iVariable = Integer
$oVariable = Objekt

Wobei ich ggf. je nach Umfang dies auch kombiniere ob Global, Lokal (+ggf. Const):

Local        $L_sName = String
Global       $G_sName = String
Global Const $GCsName = String

Aber im Endeffekt versuche ich Global im besten Fall ganz zu vermeiden und die Variable immer zu übergeben und jeder hat so ein bisschen seinen eigenen Stil.