Scratch kennt globale, lokale Variablen sowie Cloud-Variablen - schön das!
Leider ist der Sichtbarkeitsbereich einer Variable nicht so leicht zu erkennen, was leicht zu Programmierfehlern führt.

Aus leidvoller Erfahrung verwende ich nun eine feste Schreibweise für Variablennamen:

• lokale Variablen (Nur für diese Figur) klein schreiben: z.B i, tmp, myID
  
• globale Variablen (für alle Figuren) groß schreiben: z.B HIGHSCORE, IT, STACK, usw
  
• Cloud-Variablen sind bereits durch Scratch mit einer Wolke markiert. Ich verwende hier dennoch einem führenden Unterstrich und unterscheide auch hier den global/lokalen Typ durch Groß-/Kleinschreibung: _CLOUD, _myCloud
  

Vorteile: Die Variablen dann sind in der Variablenliste des Sprites nach Typen sortiert und lassen sich bei der Fehlersuche schon durch ihre Optik leichter überprüfen.

Wie macht Ihr das?

Interessant Ich mache fast all meine Variablen global, sodass ich die Unterscheidung fast nicht brauche…

Bei mir ist es bei jedem Projekt ein wenig anders, es hängt dann meist davon ab, ob ich lieber klone uns sprites verwende oder doch lieber auf stempel zurückgreife. Doch einige Regeln halte ich immer ein:
Zählvariablen benenne ich immer mit i, i2, i3 … usw, lokale zählvariablen dann meist j1, j2, j3 … .
Wichtige Variablen sind dann meistens komplett groß geschrieben. Wichtig ist eine Variable dann, wenn sie in vielen Sprites verwendung findet und da meine Projekte oft recht komplex sind und mit über 20-30+ Variablen auskommen müssen, ist es einfach bequemer ohne scrollen direkt die wichtigsten zu finden

Die restlichen Konventionen beziehen sich imemr direkt auf das Projekt.Meine Listen in meinem Speil Civilizations zum Beispiel heißen oft “object ….” oder “o …”, damit ich sofort weiß, dass hier attribute von objekten gespeichert sind. Andere heißen Inv … für Inventar Angelegenheiten usw.

Danke @Tm_ und @LiFaytheGoblin für die flotten Rückmeldungen!

Bei den ersten kleinen Projekten machte ich mir wenig Gedanken über die Art der Variablen. Aber wenn ich in größeren Zeitabständen überall mal was spontan daran bastel, werden die Sachen doch schnell mal groß und unübersichtlich … und sterben schließlich an ihrer Komplexität.

Hierbei die Übersicht zu waren, wann aus welchem Sprite und warum eine Variable geändert wird, wird dann schwierig. Die Datenkapselung mit lokalen Variablen hilft mir, die Fehlerquote klein zu halten, bzw überhaupt die Bugs zu bereinigen. Also möglichst wenig globale Daten verwenden, dann kann auch keiner aus Versehen dazwischen mengen. Mit der zusätzlichen GROSS- kleinschreibung halte ich mir das Ganze gut im Griff.

Nach und nach versuche ich auch, bestimmte immer wiederkehrende Funktionen in sog. Utility-Sprites zusammenzufassen. Die ich dann wie einfache Bausteine in andere Projekte kopieren kann. Wie bei LEGO müssen dann aber eben auch die Verbindungsstellen passen …

Bei mir sieht das ganze auch shcnell unübersichtlich aus Ich selbe rkommdamit zurecht, sogar nachdme ich schon mehrere Monate nicht an einem Projekt gearbeitet hab, aber anderen die meine Skripte verstehen wollen tue ich damit keinen großen gefallen ^^

Eigentlich bin ein ein Fan lokaler Variablen, z. B. damit Zähler immer i,k,l usw. heißen können.

Nachdem ich (noch bei Scratch 1.4) damit ein paar mal auf die Nase gefallen bin, weil irgendwelche Funktionalitäten dann doch nicht gingen, habe ich schweren Herzens darauf verzichtet und vergebe möglichst viel global. Einzige Ausnahme sind Variablen, die mit fertigen Sprites mitkommen. Solange sie funktionieren, behalte ich sie bei.

Um die Übersicht zu behalten, lege ich mir bei größeren Projekten schon mal das gute alte Data Dictionary an, d. h. ein Verzeichnis mit den verwendeten Variablen, den Objekten, in denen sie verwendet werden und evtl. Hinweisen zu Sinn und Zweck, Wertebereichen, Datentypen und zulässigen Ausprägungen.

… zum Data Dictionary fällt mir ein, das ich Dokumentation und Notizen gerne nahe beim Programmscript habe. Bei 1.4 gefielen mir die allgemeinen Projektnotes.

Die Scriptkommentare bei 2.0 passen mir dagegen nicht. Sie sind immer im Weg, auch wenn man sie kleinschaltet. Ein Kommentarblock sollte wie ein normaler Block geformt sein und klein-großschaltbar sein. Dann gibt es auch kein Chaos beim ‘Aufräumen’

Nachtrag: Hab für mich ne pragmatische Lösung gefunden Kommentar in Variable schreiben

Noch eine Frage (an mich selber):

Wie verhält es sich mit der Sichtbarkeit lokaler Variablen in Klones - wie verwalte ich Daten klone-spezifisch, z.B seine ‘Laufzeit’

Einige Werte sind ja bereits klone-lokal: x, y, Drehung, Effekte usw …

Hmmm, Lösungsansatz: eines der vordefinierten klon-lokalen Variablen z.B. die Kostümnummer als Index auf ein sprite-lokales Array ‘missbrauchen’ eine automatische Klone-Nr wäre natürlich wünschenswert.

… irgend eine andere Idee dazu?