1.: Da du selbst sagst, dass das kein Tutorial ist, und es beim Programmierstil ähnlich geil werden kann, wie mit Juristen (zwei Leute, drei Meinungen), hab ich das mal zum Diskutieren in die Expertenrunde geschoben und fang auch mal direkt mit den Widerworten an.
2.: Codestil ist so eine Sache, die man nicht global vorschreiben kann oder sollte, sondern bei der jeder für sich den Weg wählen sollte, mit dem er am besten zurecht kommt. Es gibt zwar Fundis, die mit Sprüchen wie "weil K&R das so sagen" ihre Meinung als die einzig richtige zu rechtfertigen versuchen, aber bis auf einige Ausnahmen, für die gute Begründungen finden lassen (z.B. zwischen if und dem geklammerten Ausdruck dahinter ein Leerzeichen zu setzen, weil if keine Funktion ist), gibt es immer mindestens zwei Möglichkeiten, die auch beide ihre Daseinsberechtigung haben. Deswegen sollte man mit solchen dogmatischen Regeln eher vorsichtig sein. So ein Style Guide ist dann sinnvoll, wenn man selbst ne Gedächtnisstütze braucht oder in einem Team entwickelt und sich auf einen einheitlichen Stil einigen muss, aber anderen einfach so zu sagen, was "richtig" ist, halte ich doch für etwas anmaßend, weswegen dieser ganze Thread eher mit Vorsicht zu genießen ist. Das einzige, was beim Stil wichtig ist, ist, dass er einheitlich ist (weswegen solche Richtlinien in einem Team auch wieder sinnvoll sind), aber das reicht auch schon aus, damit der Code wartbar bleibt.
3.: Du redest von IDEs, die einen beim Codestil unterstützen. Auch die setzen nur eine Standardeinstellung um, die deren Programmierer vorgegeben hat, und bieten Einstellungen, um der IDE den eigenen Codestil beizubringen.
4.: Mir fehlt bei vielen deiner Regeln eine Begründung. Wenn mir jemand vorschreiben will, wie ich etwas zu erledigen habe, ist das erste, was ich (mich) frage: "Warum?"



Ähm, ja... Du meinst wohl "pro Anweisung". Jedenfalls erinnert mich diese Formulierung an

§49 ADA schrieb:

Der Wertsack ist ein Beutel, der auf Grund seiner besonderen Verwendung im Postbeförderungsdienst nicht Wertbeutel, sondern Wertsack genannt wird, da sein Inhalt aus mehreren Wertbeuteln besteht, die in den Wertsack nicht verbeutelt, sondern versackt werden.

Und warum nicht = für Vergleiche und := für Zuweisungen? Oder, da = ja so uneindeutig ist, == für Vergleiche und := für Zuweisungen?



Vorsicht! Das ist schon keine Stilfrage mehr, diese Ausdrücke haben unterschiedliche Semantiken. False ist im GM eine Konstante mit dem Wert 0, d.h. mit "== false" testest du genau auf den Wert 0.
Die Negation macht aus Werten kleinergleich 0 eine 1 und aus positiven Werten eine 0. Insbesondere für Ausdrücke mit negativem Wert bekommst du so bei "== false" eine 0 und bei Negation eine 1.

Edit: Die Grenze ist nich 0, sondern 0.5; siehe DragonGamer.



Auch dies ist keine Stilfrage sondern hat wieder unterschiedliche Semantiken. Wenn die Variablen eines Skripts nicht mit var als lokal deklariert werden, sind sie nach Ausführung des Skripts noch verfügbar, und wenn sie als lokal deklariert werden (d.h. lokal zum Skript), werden gleichnamige Variablen der ausführenden Instanz nicht verändert. Soll heißen, wenn die ausführende Instanz schon eine Variable namens foo hat, und im Skript auf foo geschrieben wird, so wird das foo der Instanz nicht verändert, wenn foo im Skript mit var als lokal deklariert wurde. Das kann je nach Anwendungsfall mal erwünscht sein und mal nicht.



Und wieder frage ich: Warum? Diesmal allerdings nicht, weil es keinen vernünftigen Grund gibt, sondern weil der von dir genannte kein solcher ist. Es geht hier nicht um andere Programmiersprachen, sondern um GML, d.h. was in anderen Sprachen gilt, kann uns hier völlig egal sein und ist keine akzeptable Begründung für irgendwas. Gleiches gilt bei der Frage, ob man Semikola setzen soll. Wenn der Zeilenumbruch ein Semikolon ersetzt und die Länge eines Skripts sich tatsächlich auf die Laufzeit auswirkt (mir war so, als hätte MewX da mal was rausgefunden), wenn man also um jedes Zeichen kämpfen muss, ist es sogar vernünftiger, die Semikola nicht zu setzen. Durch Zeilenumbrüche und Einrückungen bleibt der Code weiterhin les- und wartbar. Und genauso kann ich mir vorstellen (ich weiß es nicht, aber vllt. hat das schonmal jemand untersucht), dass der GM beim Übersetzen der Konstanten mehr Zeit braucht, als wenn man die Werte direkt hinschreibt. In jedem Fall sind 0 und 1 kürzer als die Mnemonics, was beim Golfen hilft, wenn man wieder um jedes Zeichen kämpft.



Und wieder: Warum? Ja, es gibt Sprachen, die einen zwingen, zwischen einzelnen Zeichen und Zeichenketten als unterschiedliche Datentypen zu unterscheiden, und solche Sprachen brauchen dann zwingend unterschiedliche Auszeichnungen für Konstanten dieser Typen (' vs. "), aber der GM ist keine solche Sprache. Hier ist alles entweder eine Fließkommazahl oder ein String. Und da greift wieder, was ich ganz oben geschrieben habe: Es ist egal, welchen Stil man verwendet, solange man ihn einheitlich durchzieht. Und da ist ein Wechsel zwischen unterschiedlichen Anführungszeichen nur aufgrund der Länge eines Strings eher kontraproduktiv.

Um also nochmal auf den Anfang zurückzukommen: Ich lasse diesen Thread mal als Diskussionsplattform offen, in der man Konventionen besprechen kann, die sich als "best practice" bewährt haben, aber wenn man anderen Vorschriften machen oder sie von seinem Stil überzeugen möchte, sollte man eine vernünftige Begründung angeben können. Und nein, "aber die Sprache hat auch" ist keine vernünftige Begründung.

CAS hat das sicher bedacht nur wollte er sagen dass man eben nicht immer var benutzen soll sondern immer bedenken was gewollt ist.
Du hattest es ein wenig so dargestellt als ob mit oder ohne var das selbe wären, nur letzteres "besser".

Übrigens
!0.499 wird auch als "wahr" angesehen denn der GM verstehet alles < 0.5 als false und alles andere (inklusive 0.5) als true.
Also sollte man da wirklich aufpassen..


Ansonsten habe ich nur einen "Kritikpunkt":
Meiner Meinung nach wird das Einrücken maßlos überschätzt.
Wieso soll
Übersichtlicher sein als
Wenn du mich fragst ist letzteres übrsichtlicher. Es ist insgesamt kürzer und man kann vernünftig von oben nach unten lesen und muss nicht ständig leere Stellen überspringen und schauen wo es weiter geht.
Bei deutlich längeren Skripten erhöht es die Übersichtlichkeit auch nicht deutlich. Eher im gegenteil denn wenn man durch drei Bildschirm-Höhen aus Code Scrollt weil man z.B. das Ende einer if-Abfrage sucht, verliert man doch sowieso aus den Augen wie weit das Gesuchte genau eingerückt war. Dieses Problem bestünde nicht wenn der GM Linien benutzen würde die das einrücken anzeigen. Das tut er allerdings nicht und man ist man doch wieder darauf angewiesen einfach die richtige, schließende Klammer zu finden und dabei hilft der GM ja durch den highlighter.
Ich finde man sollte das Einrücken nur dann verwenden wenn es wirklich die übersicht erhöht und niemals mehr als zwei.. höchstens mal drei Einrückungsstufen verwenden.
Solche sinnvollen Stellen könnten z.B besondere Statements sein (Schleifen, with, etc)
oder wenn man else's und Einzeiler hat:


Insgesamt sind deine Tips aber schon nützlich und wie CAS richtig gesagt hat, eine Richtlinie.


Zur Semikolon-thematik:
Hatte das damals auch nachgeprüft und festgestellt dass es im neueren GM keinerlei Unterschied in der Laufzeit mehr gibt. Früher dürfte das aber anders gewesen sein denn der GM benutzt erst seit 7.0 oder 8.0 diesen mysteriösen "bytecode" bei dessen Erstellung ziemlich sicher Semikolons usw. entfernt werden. D.h. zumindest die "Kompilierzeit" (also die Zeit die zum Exe erstellen gebraucht wird) könnte minimal durch die überflüssigen Zeichen beeinflusst werden.
Übrigens werden beim Verarbeiten zu Bytecode auch wohl alle möglichen Rechnungen mit echten Zahlen aufgelöst denn in der Laufzeit von a = 1+20*4+3-14; ist im Spiel dann genau so lang wie von a = 70.

1.: Diesen Unterschied gibt es im GM aber nicht, da der GM nunmal nur zwei (primitive) Datentypen hat, und true und false nur Konstanten für Zahlen sind.
2.: Was in den meisten Fällen gemeint ist, spielt keine Rolle. Bei Stilfragen geht es darum, welche von mindestens zwei Schreibweisen mit äquivalenter Semantik verwendet werden soll, damit für den gleichen Zweck immer gleich aussehender Code verwendet wird. Das mag ja alles seinen Sinn haben, aber es setzt eine wichtige Sache voraus: Die zur Diskussion stehenden schreibweisen müssen auch alle äquivalente Semantik haben, und das haben diese beiden Schreibweisen nunmal nicht. Es gibt Eingaben, die bei beiden Ausdrücken unterschiedliche Ausgaben erzeugen, und damit ist dies keine Stilfrage mehr, sondern eine Frage dessen, was genau der Programmierer an dieser Stelle eigentlich will. Genauso wie die Verwendung von var: Mal will man lokale Variablen verändern, mal nicht, wesegen man sich immer wieder überlegen muss, ob man nun var verwendet, oder nicht; zu sagen "verwende immer var" oder "verwende niemals var" ist keine Stilfrage.



Wenn man die Sprache wechselt, gelten ohnehin andere Spielregeln. Jede Sprache hat ihre Eigenheiten, auf die man sich einstellen muss, wenn man diese Sprache lernt. Einen möglicherweise leichteren Umstieg zu versprechen ist somit ein genauso schwaches Argument für irgend eine Code-Konvention, wie "aber diese Sprache macht das doch auch". Du hast z.B. vorgeschlagen bei Zuweisungen Leerzeichen vor und nach dem Zuweisungsoperator zu setzen. Ich kann dir eine Sprachfamilie nennen, bei der du keine Leerzeichen setzen darfst (zumindest nicht vor dem Operator), weil die Variable, auf die geschrieben werden soll, sonst nicht als Variable sondern als Befehl interpretiert wird.
Nochmal: Es geht hier um GML, und da ist es verdammt nochmal egal, was andere Sprachen so treiben.



Microsoft, Oracle, Google und wie auch immer sich die Gruppe nennt, die am Kernel rumschreibt. Das unterstreicht nur, was ich vorher schon gesagt habe: Es ist sinnvoll, Code-Konventionen einzuführen, wenn man gemeinsam an einer Sache arbeitet, aber es gibt nicht den Stil (was man schon an religiösen Streitfragen sieht, die heute noch Communities spalten, z.B. wo öffnende geschweifte Klammern zu stehen haben, oder womit man einrückt (ein Leerzeichen? zwei Leerzeichen? vier Leerzeichen? Tabulator?)), selbst, wenn man sich nur auf eine Sprache beschränkt. Das von dir verlinkte sind jeweils nur die Richtlinien, die diese vier Gruppen für sich verwenden und für den Rest der Welt veröffentlicht haben.

Außerdem finde ich das ziemlich einseitig, dass, wenn du dich schon auf andere Sprachen beziehst, nur Sprachen mit C-Syntax bedenkst, zumal der GM doch immer noch ein Hybrid aus C und Pascal ist.



Ach verdammt! Das bringe ich doch jedes Mal wieder durcheinander... -.-
Danke.