- Offizieller Beitrag
Ich denke, die meisten deklarieren Variablen, wenn sie nicht innerhalb einer Funktion sind, als Global.
Nun habe ich von Valik (EN-Forum) einen interessanten Beitrag zu diesem Thema gefunden, den ihr euch mal zu Gemüte führen solltet.
Ich habe eine Übersetzung gemacht und hoffe, dass ich das Wesentliche getroffen habe. Falls ihr fehlerhafte Inhalte findet - bitte melden. (Besonders bei den umgangssprachlichen Einlagen hab ich mich etwas schwer getan). Einen Text 1:1 übersetzen ist, wie ihr von der Hilfe-Übersetzung wisst, nicht so easy und es ist besser, wenn nochmal wer querliest.
Im Text ist ein Link enthalten, dessen Inhalt ich aber nicht extra übersetzt habe.
[Valik] Why Global variables are bad
Übersetzung
Globale Variablen können zu unerwarteten Ergebnissen führen, s. hier. Ich war dabei ein Problem mit AutoIt und Aut2Exe zu fixen, welches beinhaltete, zwei getrennte (und fast identische) Listen von Funktionsnamen zu unterstützen. Habt ihr euch jemals gefragt, warum wir manchmal ein Release ausgeben würden (wie 3.3.5.0), welches nicht eine Funktion kompilieren konnte, aber es konnte laufen? Das ist, weil wir vergaßen, die Aut2Exe zu aktualisieren. Die von mir gezeigte Lösung, löste ein zusätzliches Problem. Es stellte sich heraus, dass in Reihenfolge der Benutzung der Array-Initialisierungs Syntax eine temporäre Lokale Variable erstellt und anschließend in eine 'heap-allocated' Variable kopiert wurde. Ein unangenehmer Leistungserfolg (fast 400 Element-Array mit 16 - 24 Bytes pro Element (32 Bit, 64-Bit-Größen)), der notwendig war, weil jede andere Weise, solch eine massive Struktur zu schaffen, geradezu grotesk sein würde. Ich schrieb den Code um, um statische Klassenmitglieder und die Tatsache auszunutzen, dass sie noch mit der Array-Initialisierungsprogramm-Syntax deklariert werden können. Die Klasse wurde entworfen, um beerbbar zu sein und erforderte nahezu Null Veränderungen zum vorhandenen Code um einfach magisch die vorherige Liste (geschützte Mitglieder mit identischen Namen) zu ersetzen. Alles sah gut aus (und es war gut), bis ich es ausführte. Das Problem war, es stürzte ab. Sehr seltsam. Es stellte sich heraus, dass die globale Klasse die von der neuen Klasse erbte, erstellt wurde und versuchte die Funktionsliste zu verwenden, bevor diese Liste initialisiert wurde. In einer Anwendung, die globale Variablen nicht missbraucht, würde das nie geschehen. Das statische Mitglied würde initialisiert, bevor main() jemals aufgerufen wird, und alles wäre gut. Statische und globale Variablen werden in der Reihenfolge initialisiert in der auf sie getroffen wird. Ich hatte also eine 50-50 Chance, um Glück zu haben, aber ich hatte es nicht. So musste ich die Klasse umschreiben und verwandelte sie in einen Pseudocontainer, um von lokalen statischen Variablen Gebrauch machen zu können. Ich verbrachte viel Zeit, diese Klasse umzuschreiben. Erwähnte ich, dass sie Templates und Makros (zusammen) verwendet? Ja, es ist ein Durcheinander. Der Compiler meckert und du bekommst keine genaue Idee, worin der Fehler besteht, weil er sich über ein hinter einem Makro verborgenes Template-Problem beklagt. Ich schweife ab...
Diese Geschichte schließt auch Aut2Exe ein. Offensichtlich wurde meine Klasse entworfen, um in Aut2Exe ebenso verwendet zu werden, eine einzelne Liste statt zwei Listen zur Verfügung zu stellen. Ich nahm die passenden Änderungen mit Aut2Exe vor, baute sie ein und versuchte es auszuführen. Und es stürzte ab. Dieses Mal betraf es nicht nur meinen Code. Nein, es stellt sich heraus, dass Aut2Exe genau das gleiche Problem hatte, bevor ich jemals darauf stieß. Seit Jahren hat Aut2Exe nur durch eine reine Chance gearbeitet. Ich hatte erwähnt, dass die Chance bei 50-50 liegt? Gut, Aut2Exe hat damit seit Jahren gelebt. Ich habe keine Idee, warum es sich plötzlich dafür entschied zu crashen, als ich an Teilen ohne Beziehung zum Code arbeitete. Es verwirrt mich, warum es entschied, heute Abend war die Nacht, in der es in der Hölle speisen wollte. Aber lieber heute Nacht, wenn das Problem noch frisch ist, als später, wenn ich es wieder vergessen hab.
Das war nicht das erste Mal, dass das beides geschehen ist. Ich habe ziemlich viele globale Variablen von den verschiedenen Tools im Laufe der Jahre entfernt. Ich brauchte ungefähr 25 Minuten, um den Crash nachzuvollziehen, als er heute Abend erstmalig geschah. Es brauchte nur 25 Sekunden bis zum nächsten mal. Ich habe viel Erfahrung mit dem Debugger, der Sprache und mit dem Bug insbesondere, so verschwendete ich nicht Tage mit dem Versuch, es ausfindig zu machen. Ihr könnt nicht dieses Glück haben, wie auch immer. Dies ist ein sehr übler und raffinierter Fehler. Er kann leicht verhindert werden, indem man so wenig wie möglich Globale Variablen verwendet. Klassen definieren, die andere abhängige Objekte richtig als Parameter akzeptieren und Referenzen/Pointer dazu speichern führt zu viel weniger Kopfschmerzen als den bequemen Weg zu nehmen und gemeinsam nutzbare Objekte als Globale Variable zu verwenden. Nehmt euch Zeit, es von Anfang an richtig zu tun, und ihr werdet nicht Stunden verbringen, um bei einem seltsamen Crash einen Fehler zu beseitigen, der aus dem Nirgendwo erscheint, wenn ihr Veränderungen vornehmt, die ohne Beziehung zum Code sind.
Die Quintessenz ist also: Vermeidet/Minimiert Globale Variablen. Hier mal Beispiele, wie man es machen kann:
Spoiler anzeigen
;===============================================================================
; EDIT: Punkt 1 gestrichen, wie die Diskussion ergeben hat, war dies schlicht unsinnig.
;===============================================================================
;============== 2. Vermeidung Globaler Variablen
#cs
Warum soll ich überhaupt Globale Variablen verwenden? Hier wird meist die Antwort kommen:
'Damit ich den Inhalt in verschiedenen Funktionen nutzen/verändern kann.'
Aber das läßt sich auch anders lösen:
#ce
Local $myVar = 0
[/autoit] [autoit][/autoit] [autoit]_PlusEins($myVar)
ConsoleWrite('$myVar: ' & $myVar & @CRLF)
; im Funktionskopf muß nicht der identische Variablenname stehen, erleichtert aber das Lesen
; die Variable wird der Funktion 'ByRef' übergeben ==> sie kann somit von der Funktion verändert werden
; ohne 'ByRef' erfolgt die Übergabe immer 'ByVar', d.h. eine Kopie der Quellvariable wird erzeugt
Func _PlusEins(ByRef $myVar)
$myVar += 1 ; kein Return erforderlich, da die Variable in ihrer Quelle geändert wird
EndFunc
Sicher kann man sagen: 'Ist mir noch nie passiert, solch Trouble.' Nun halte ich eine 50-50 Chance zum Crash durchaus für eine Größe, die man nicht unter den Tisch kehren sollte. Und es ist wirklich kein großes Problem, sein Programmierverhalten anzupassen und somit diesem Stolperstein von vornherein aus dem Weg zu gehen.
Edit:
Danke für die geführte Diskussion - hat mir auch einige Punkte etwas näher gebracht und auch die Erkenntnis, dass mein Gedanke, mittels Enumeration von Indexvariablen ein Array zu addressieren, hierfür schlicht blödsinnig ist.
Allen Lesern dieses Posts möchte ich naheliegen, das Schlußwort von AspirinJunkie unbedingt zu lesen.