Vorschläge

Auf dieser Seite können und sollen Vorschläge für neue Seiten, Themen und Ergänzungen im Wiki gemacht werden. Insbesondere bei Punkten, zu denen es mehrere Möglichkeiten/ Ansichten gibt, sollen diese hier zunächst abgestimmt und diskutiert werden, bevor ein entsprechender Eintrag im Wiki vorgenommen wird.

Nach Umsetzung eines Vorschlags, kann dieser dann hier wieder gelöscht werden.

Es sollte eine Seite geben, auf der es eine „Richtlinie für guten Coding Stil“ gibt.
Beispiele:

for i=1,5,1 do    -- schlechter Stil
for i = 1,5 do    -- guter Stil
 
if Logic.GetDiplomacyState (1,2) == 3 then                   -- schlechter Stil
if Logic.GetDiplomacyState(1, 2) == Diplomacy.Hostile then   -- guter Stil

Ich fände so eine Übersicht sehr sinnvoll, da nicht jeder gelernter oder hauptberuflicher Programmierer ist. Ein kurzer Kommentar warum das „guter Stil“ ist sollte bei jedem Beispiel mit eingefügt werden. _Netsurfer

OK - Noigi

ob for i = 1, 5, 1 do end schlechter Stil ist, kann man sich streiten. Ich persönlich skripte immer so (wer sich das KI-Script ansieht, wird es bemerken), da ich es als eindeutiger finde und der Code, für mich persönlich, besser lesbar ist. Ich würde sagen, der einzige Vorteil ist, dass ein paar Bytes weniger benötigt werden _{Old McDonald}

Da hast du wohl Recht, zumal es beim zweiten Beispiel ja genau umgekehrt ist (was das Einsparen anbelangt) ! Das zeigt, wie sinnvoll es ist, solche Dinge vorher zu diskutieren. Also noch zusätzlich differenzieren zwischen Muss, Optional und Guter Stil? Ich vermisse auch noch mehr Beispiele … _Netsurfer

Also mir scheint dieser Punkt stößt auf wenig Gegenliebe, wahrscheinlich ist er auch „zu umfangreich“, wenn man ihn möglichst komplett erfassen will. Ich schlage daher vor, ihn dahingehend vom Topic her zu ändern, als daß er nur Dinge enthält, die man auf gar keinen Fall tun sollte. — Gunther 2005/11/26 01:31

Wenn wir nur einen Punkt „auf keinen Fall a oder b machen“ erstellen, dann wird der Code im Wiki zu uneinheitlich, weil zu vieles offen bleibt.

Bei dem obigen Beispielen sollte man denke ich zwischen zwei Dingen unterscheiden: a) Wie schreibt man etwas b) Was verwendet man.

D.h. bei „for“ ist es das „wie“. Bei „3“ bzw „Diplomacy.Hostile“ das „was“.

Es gibt denke ich mehrere Anforderungen an den Code: 1) Einheitlich 2) Lesbar/verständlich 3) Kurz/Frei von überflüssigen Dingen 4) Konventionen nicht „überreguliert“

Einheitlich bekommen wir den Code, indem wir hier entsprechende Konventionen festlegen, die alle nach dem gleichen Muster gestrickt sind, und möglichst ohne Sonderfälle auskommen.

Lesbar… dazu gibt es ja schon Beispiele, also nicht a=6*b+89-c()+34^d sondern a = 6 * b + 39 - c() + 34^d (optional noch mit Klammern und besseren Variablennamen), oder eben foo() und nicht foo ().
Beim Thema kurz/überflüssig gibt es ja schon vieles was ausgeräumt wurde. Konkret zum for Beispiel: Der Standardfall bei einer for Schleife ist „zähle von 1 bis x in Schritten von 1“. Daher auch die Kurzschreibweise for i = 1, 5 do. Wenn man soetwas im Code sieht, dann denkt man sich „aha, 2 Parameter, alles klar“. Dies in Langschreibweise ( for i = 1, 5, 1 do ) zu schreiben halte ich für unpraktisch. Einerseits ist die letzte 1 unnötig/überflüssig, andererseits „Oh ein dritter Parameter, da muss etwas besonderes sein.“ Daher halte ich es auch für einfacher lesbar wenn es nur 2 sind. In diesen Bereich fällt auch die Sache mit dem optionalen Semikolon…
Ein anderer Punkt ist auch die Parametertrennung. foo(„abc“,cde,56,i + 23,„xyz“) oder foo( „abc“, cde, 56, i + 23, „xyz“ ). Ich bevorzuge da die zweite Schreibweise, also ein Leerzeichen nach einer öffnenden- und vor einer schliessenden Klammer, sowie ein Leerzeichen nach einem Komma mit folgenden Parametern in der gleichen Zeile.
Dazu kann man wohl noch eine Menge schreiben… — Chromix 2005/11/30 17:15

Ich glaube, dass sich das kaum umsetzen lässt, denn jeder der schon Coded hat ja bereits seinen eigenen „Stil“ und seine speziellen Vorlieben. Keiner wird freiwillig für sich davon abweichen. Dennoch würde ich es sehr begrüßen, wenn der Codingstil hier im Wiki einheitlich wäre, was bedeuten würde, dass man halt seine Funktionen, sofern sie ins Wiki sollen, entsprechend „umstricken“ müsste.

Zu den von dir genannten Beispielen: Denk' dran - es sind nicht alle User Programmier-Profis. Bei mir tauchte bspw. die Frage auf, ob ein Semikolon am Zeilenende Pflicht ist (wie bspw. bei PHP). Und auch bei der for-Schleife kann man das andersherum betrachten: Grundsätzlich hat eine for-Anweisung 3 Parameter! Dass es auch einen Standardwert für den 3. Parameter gibt, der eine „Kurzschreibweise“ erlaubt ist etwas ganz anderes .

Da sich ja (leider) nach wie vor nicht „hunderte“ User hier betätigen, sollten wir vielleicht eine Umfrage unter den Aktiven starten, um den größten gemeinsamen Nenner für die Code-Konvention zu finden, sodaß jeder nur ein Minimum an Änderungen an seinem Code vornehmen muss. Man könnte aber auch ein (PHP-)Script erstellen (hallo nevermind!), welches den Großteil dieser Arbeit übernimmt (ich würd' das ja machen, aber leider gehören RegExp nicht zu meinen Stärken ). — Netsurfer 2005/11/30 17:53

Vielleicht sollte man bei manchen Dingen auch noch die Update-Sicherheit bedenken. Gerade die Frage der Diplomatie ist dafür ein gutes Beispiel:

Angenommen, durch das Update von 1.05 auf 1.06 wird der Rückgabewert bei Feindschaft von 3 nach 1 umgeändert. Was nun? Da beim Update auch Diplomacy.Hostile umgestellt werden würde, hätte das keinerlei Auswirkungen. Wenn aber statt Diplomacy.Hostile 3 geschrieben wird, so werden eben nicht mehr die gewünschten Effekte erreicht.

Gegen die Leerzeilen habe ich nichts, Semikolons verbessern meiner Meinung nach die Lesbarkeit, denn es ist sofort erkennbar, wo die Anweisung endet, was nicht immer der Fall ist. Hier mal ein Extrem-Beispiel:

x = y + 1 y = doSomething(createEntity) x = y - 1
a = b -
y c = doNothing() == 1 

Mit Semikolons wird das dann wenigstens ein bisschen lesbarer:

x = y + 1; y = doSomething(createEntity); x = y - 1;
a = b -
y; c = doNothing() == 1; 

Natürlich würde man normalerweise nicht so schreiben.
Es gibt allerdings einen Nachteil bei den Semikolons: Es existieren keine „leeren“ Anweisungen wie in manchen (Programmier-)Sprachen. Dann entsteht ab und zu ein Syntax-Fehler. Dafür kann man allerdings auch mal ein Semikolon vergessen

Wie schon geschrieben, bin ich bei der for-Schleife nicht ganz einverstanden, aber das sollte auch nicht weiter schlimm sein. Ihr könnte trotzdem eure Konvention festlegen _{Old McDonald}

Ich hab zwar auch erst mit Semikolons in Lua gearbeitet, das sie aber optional sind, hab ich es mir abgewöhnt. Und wenn man in Lua nur einen Befehl pro Zeile schreibt, wie es wohl auch gedacht ist, werden die Dinger einfach überflüssig. Ich nehme an, das die nur da sind, um C/C++ Programmierern das Leben leichter zu machen. Wie man z.B. in Java „int[] i“ statt wie in C/C++ „int i[]“ schreiben soll, aber trotzdem keine Fehler mit dem C-Style entstehen. In PHP ist der Zugriff auf ein einzelnes Zeichen in einem String auch mit dem Array-Index Operator „$s[2]“ möglich, es sollte aber besser „$s{2}“ heißen, da ein String nunmal kein Array aus chars ist, sondern ein String eben. So verhält es sich dann auch mit der for Schleife. Ich finde da sollte man Lua als Lua akzeptieren; die Semikolons weglassen, den Post-Inkrement Ausdruck der for Schleife auch. — nevermind 2005/12/02 18:55

Um eine möglichst einheitliche Vorgehensweise beim Coden zu errreichen, sollte man eine Seite im Wiki einrichten, auf der entsprechende Namenskonventionen vorgegeben sind.
Beispiele:
Generell gilt: „Amtssprache“ sowohl für LUA, als auch DEdK ist Englisch.

• Helden: Helden im Script mit ihren Namen benennen, wobei der 1. Buchstabe groß geschrieben wird, also die Entity „PU_Hero1“ erhält den Scriptnamen „Dario“
• Funktionsnamen: Funktionsnamen sollten so gewählt werden, dass sie eine logische Beziehung zu der Aufgabe der Funktion bilden, wobei der erste Buchstabe groß geschrieben werden sollte. Bei Zusammensetzung aus mehrereren Wörtern (auf die Länge achten), diese ohne Leerzeichen oder Unterstrich aneinanderhängen, wobei wiederum der jeweils erste Buchstabe eines Wortes groß geschrieben werden sollte. Außnahme: Funktionen können mit einem Präfix und einem Unterstrich vor dem Funktionsnamen gekennzeichnet werden. Beispiele:

  function Name()
  function CreateArmyTwo()
   
  function ArmySeven_Create()
  function ArmySeven_Control()
   
  function Callback_CountdownTwo()
   
  function NPC_CreateMajor()
   
   
  function Briefing_Intro()
  function Briefing_Major()
  function Briefing_Outro()
   
  function Cutscene_FlyAround()

• Variablennamen: Bei Variablennamen sollte man differenzieren zwischen globalen und lokalen Variablen. Globale Variablennamen sollten am Anfang groß, und lokale Variablennamen klein geschrieben werden. Ebenso sollte wie bei den Funktionsnamen auf eine logische Beziehung zwischen Variablenwert und Variablenname geachtet werden. Auch ist die Verwendung von Ziffern in Variablennamen zu vermeiden - ersatzweise können Begriffe wie „first“, „second“, „third“, usw. verwendet werden.

Mit Letzterem bin ich nicht einverstanden, das sollte man so ergänzen:

lokale Variablen sollten klein geschrieben werden,

globale Variablen sollten groß geschrieben werden _Tenji

Da die anderen damit ja auch einverstanden zu sein scheinen, habe ich das mal geändert, da ich das auch als sinnvoll erachte. _Netsurfer

Ich bin soweit einverstanden _Siedlerchr

O.K. _{Old McDonald}

Ich bin dafür globale Variablen mit einem gv Präfix zu Kennzeichnen ;) _nevermind

Das ist ja die von BB verwandte Methode und beinhaltet dadurch ein erhöhtes Risiko von Namenskollisionen. _Netsurfer

Also ich ziehe mal ein Zwischenrésumée:
Einigkeit scheint darin zu bestehen, dass man zwischen globalen und lokalen Variablen unterscheiden sollte.
Die Frage ist aber nun wie: Entweder wie Tenji vorgeschlagen hat durch Groß- und Kleinschreibung am Anfang, oder gemäß Neverminds Vorschlag durch Voranstellen von „gv“ bei globalen Variablen.
Noch irgendwelche anderen Vorschläge, bzw. Meinungen zu den Varianten?
Hinzukommt ja noch der Punkt, dass lokale Variablen in bestimmten Bereichen auch durchaus global sein können _Netsurfer

Vielleicht könnte man sich dann auf den Präfix „gu“ für globale-userVariable oder „gvu“ für globale-variable-(von)usern einigen? _Tenji

Da sich die Fälle mehren, in denen die Scripte aufgrund ihrer Größe extern eingebunden werden müssen, macht es auch hier Sinn, eine einheitliche Vorgehensweise vorzuschlagen. Mein Vorschlag hierzu wäre die unter Tutorials > Allgemeines > Sonstiges beschriebene Vorgehensweise zu verwenden.

Vielleicht sollte man diese Konvention etwas erweitern, um Namensüberschneidungen zu verhindern. Bei rein mapbezogenen Skripts sollte man ausschließlich die Dateinamen „Map_Name.lua“ nennen. Das verhindert solche Überschneidungen. _{Old McDonald}

Ja, dem stimme ich voll und ganz zu. Stellt sich noch die Frage, wo und wie man den Punkt ins Wiki einfügt? _Netsurfer

Nein, nicht ganz, wieso sollte ich Das KI Script genauso wie die Map nennen? Bei mir heißt das aiscript-1-10.lua
Was anderes wäre: einheitliche Ordner-Endungen, z.B. Nur 7z oder rar oder zip, aber nich jede Beispielkarte in nem anderen Format! _Siedlerchr

Das hast du falsch verstanden. Old McDonald schrieb:„Bei rein mapbezogenen Skripts sollte man ausschließlich die Dateinamen „Map_Name.lua“ nennen.“! Das KI-Script bspw. ist ja eben genau kein rein mapbezogenes Script! _Netsurfer

Ja, schon möglich!, beim KI Script testz ich den Versionsprüfer noch, aber soweit OK _Siedlerchr

Ein externes Mapscript genau wie die Map zu nennen halte ich auch für sinnvoll. Sonstige externe Scripte (da haben wir ja momentan nur das AIScript), können also einen anderen Namen haben. Bei einem Maprelease würde es wahrscheinlich, sofern keins der Scripte modular ausgetauscht werden soll, Sinn machen, alle externen Scripte in das externe Mapscript zu kopieren, so daß nur eine Zusatzdatei pro Releasemap benötigt wird. — Chromix 2005/11/24 15:25

Mal abgesehen davon, dass das eigentlich unter den Punkt Namenskonvention fällt, sollte man vielleicht auch direkt dazu übergehen eine einheitliche Namensgebung für z.B. die User Comfort-Funktionen (UCF_Xyz) festzulegen, damit man mit Modulen arbeiten kann. — Gunther 2005/11/25 16:37

Dieser Punkt ist wohl soweit, daß er ins Wiki eingefügt werden kann. Jemand irgendwelche Einwände? — Netsurfer 2005/11/25 16:37

Die Namen von Beispielmaps sollten alle mit dem Kürzel Demo_ beginnen. Außerdem sollte am Ende durch das Anhängen von _x1 oder _x2 kenntlich gemacht werden, ob es sich um eine Nebelreich- oder Legendenmap handelt. Wenn möglich sollten die Demo-Maps in beiden Versionen bereitgestellt werden.

Eine Legenden Demo-Map zur Funktion SetupXyz sollte also Demo_SetupXyz_x2 heißen.

Ferner sollte die Map intern nicht anders benannt werden, als die eigentliche Map-Datei. Falls Scripte extern eingebunden werden müssen, sollten diese relativ über den maps\user\ Ordner eingebunden werden und ebenfalls wie die Map benannt werden.

Demo_ ist gut, aber die Endungen sollten doch eher _xN und _xL heißen! Dann ist die Zugehörigkeit deutlicher. _Tenji

Ja, das ist eigentlich egal - hauptsache es ist erkennbar für welche Version . Du hast an „Nebelreich“ & „Legenden“ gedacht, und ich an die Verzeichnisse „extra1“ & „extra2“ _Netsurfer

Auf der Mapbase wird auch extra1 & 2 verwendet. Wenn es also relativ egal ist, ob nun N oder 1, können wir ja zugunsten der Einheitlichkeit x1/x2 nehmen. — Chromix 2005/11/24 15:20

Bisher wurden die Signaturen hinter Kommentaren immer per Hand mit <sub> erstellt. Ich habe inzwischen den Mechanismus, mit dem die eMail Adressen (für automatisierte eMail Adresssammler) unkenntlich gemacht werden, ein wenig umgestellt. Daher denke ich, daß man diese nun verwenden kann. Per Signaturknopf bzw ALT + Y wird der verlinkte Nick mit Uhrzeit/Datum eingefügt. Dadurch kann man nun bequem die Signatur einfügen, und es ist auch ersichtlich wann der Kommentar geschrieben wurde.
Das Format der Signatur kann ich natürlich noch ändern, wenn es Verbesserungsvorschläge gibt. — Chromix 2005/11/24 15:30

Mir ist beim Durchschauen der Befehlsreferenzen aufgefallen, dass die Beschreibungen daneben größtenteils auf Englisch sind. Wenn dies nicht aus einem bestimmten Grund ist, würde ich sie übersetzen. _fuzi

Ich denke, dass bisher nur alle zu faul dazu waren ! Also leg' los! — Netsurfer 2005/11/30 17:30

Ist gut. Spätestens am Freitag ist das Erste fertig

Ich schlage vor, dass man die Seite Wusstest du schon? vom Aufbau her umgestaltet. Es gibt mittlerweile viele nützliche kleine/ kurze Tipps & Tricks (im Forum), die nach Themen/ Gruppen geordnet (ähnlich wie bei den Tables mit <functionslist>) dort gut aufgehoben wären. Ich bin der Meinung, dass die jetzige Struktur mit zunehmendem Inhalt „zu unübersichtlich“ wird. Auch sollte die Struktur möglichst einfach gehalten sein, damit wirklich jeder einen Tipp einfügen kann. — netsurfer 2005/11/26 01:24

Dann leg mal los ;) — nevermind 2005/11/26 19:51

Hier ist ein erster Entwurf. So, oder so ähnlich stelle ich mir das vor. Wichtig finde ich, dass jede Seite über ein entsprechendes TOC verfügt (daher die Formatierung so wie sie jetzt ist) — netsurfer 2005/11/27 14:56

Das Design ist OK. Es stellt sich nur die Frage nach dem Inhalt. Ich denke, daß beispielsweise die Infos zu den Briefings besser im entsprechenden Tutorial aufgehoben wären. Folglich: Was soll dort stehen? — Chromix 2005/11/30 16:19

Wie der Name schon sagt: „Kurze“ Tipps/ Hinweise , bzw. ein kurzer Extrakt aus anderen Tuts/ Artikeln. Oder aber Tipps, für die sich eine eigene Seite nicht lohnt. Natürlich kann/ sollte man wenn vorhanden auf die entsprechenden anderen Seiten im Wiki verlinken. — Netsurfer 2005/11/30 17:26

Ich habe wie schon im Forum erwähnt festgestellt das die Seite allgemeines mittlerweile recht lang geworden ist. Ich denke es würde der Übersichtlichkeit dienen wenn man die Bereiche Grundlegende Scriptelemente, Standardscript, Tutorials sowie Limitierung der Scriptläge als eigene Unterseiten fasst. Dann würde ich noch eine weiter Unterseite Schreibstile vorschlagen. man erreicht die betreffenden Themen schneller und muss nicht soviel klicken/scrollen. Vielleicht wäre es dann sinnvoll auch den Briefingvergleich der ja erklärt wie der alte Schreibstil zum neuen Schreibstil eingekürzt wird in den Bereich Schreibstile mit einzubinden. Was haltet ihr davon? — Ninobi 2007/01/15 21:32

Die Problematik der Scriptlänge ist nicht mehr so groß und kann deswegen eigentlich deutlich gekürzt werden (z. B. „Sonstiges“ und „Limitierung der Scriptlänge“ zusammenführen)

Das Problem des Titels Allgemeines ist halt, das man alles darunter packen kann, und wenn man nicht weiß, wohin es gehört, wird es unter Allgemeines dazugequetscht.
Vor allem der Abschnitt „Standardscript“ sprengt den Rahmen. Er sollte vielleicht ausgelagert werden und ein entsprechender Verweis hinzugefügt werden.
_{Old McDonald 2007/01/16 17:45}

Ich denke, dass sollte man(n) (Frau auch) einfach machen. Alles was nur etwas Hand & Fuß hat (und eine gewisse Logik inne hat), ist besser, als die jetzige Situation. — Netsurfer 2007/01/16 20:09

Gut ich hab das soweit vorbereitet, nun würd ich gerne meinen Vorschlag erstmal vorstellen bevor ich es umsetze und eure Meinung hören. Nur weiß ich jetzt nicht so recht wohin damit … auf den Playground? Und diesen dann später wiederherstellen? (Vorbereitet heißt ich hab es auf meinem Rechner als Textdatei…) — Ninobi 2007/01/17 22:12

Mach' es einfach und behalte deine lokale Kopie. Wenn es aus irgendwelchen Gründen nun überhaupt nicht passen sollte was du gemacht hast, lässt sich ja leicht der vorherige Zustand hier im Wiki wiederherstellen. — Netsurfer 2007/01/18 01:47

Ja, das Standardscript sprengt ein wenig den Rahmen. Und die Scriptproblematik kann auch verkürzt werden. Also erstmal alles auf eigene Seiten, und dann als Unterpunkte von Allgemeines verlinken. — Chromix 2007/01/18 09:44

Erledigt ;) — Ninobi 2007/01/18 21:20

Hab die letzten Tage damit verbracht mir die Tutorials-Übersicht mitsamt verlinkung mal genauer zu betrachten. Sie ist extrem lang geworden und dadurch wirkt sie etzwas unübersichtlich. Hab mir alle Seitenaufrufe von dieser Seite mal in eine Tabelle gebracht und Oberbegriffen zugeordnet. Wobei mir klar ist das alles was ich unter „Nützliche Spielfunktionen & Scriptlösungen“ packen würde eigentlich auch in den Bereich „kleinere Funktionen“ passen würde. Nur denke ich das eben auch diese besser unter der Tutorial-Übersicht aufgehoben wären. Was haltet ihr davon? Habt ihr noch Anregungen/Ideen? — Ninobi 2007/02/03 23:00

Die Tutorials sind furchtbar unstrukturiert, daher sollte man da dringend was machen. Also leg los…

Anmerkung: Wenn ihr mit einem Vorschlag in der gemachten Art & Weise einverstanden seid, dann schreibt bitte kurz „OK“, damit man weiß, dass ihr den Vorschlag gesehen/ gelesen habt!

OK