coding conventions

frodenius · **Verfasst:** 31.08.2007, 14:18

so zu diesem thema würd ich jetzt einfach mal nen vorschlag machen, obwohl das meiste davon sowieso jeder macht..
erste priorität des codes: lesbarkeit/klarheit und dann irgendwann geschwindigkeit..
(wir sind ja keine obfuscating-code challenge)

whitespaces werden großzügig verwendet
{ und } kriegen eine eine eigene zeile außer es tut der übersichtlichkeit keinen abbruch, wie zb bei }else{
die einrückung beträgt 4 leerzeichen (kein tabulator)
nur eine anweisung pro zeile
namen für funktionen und variablen fangen klein an, für klassen, aufzählungen, strukturen groß
kommentare nur mit //, } am ende eines langen blocks kriegen auch nen kommentar
natürlich sind variablen-namen und kommentare sinnvoll gewählt/verteilt..
jede datei kriegt einen head-comment
datei-endungen sind .h und .cpp
die dateien heißen wie die klassen darin
nur klassen-deklaration im header, KEINE definition!! selbst inline-funktionen! (ausnahme: leere funktionen, wie zb destruktoren)
keine makros, sondern inline funktionen
keine defines, sondern const-vars
überhaupt const am besten ständig verwenden
dasselbse gilt für assert (lerne es lieben) (und wenn möglich invariant/valid-prüfungen)
späte variablen-deklaration. erst wenn man sie braucht.
konstruktoren mit initialisierung (ein leerer der nur initialisiert kann auch inline deklariert werden).. alles! initialisieren

und zum svn: erst lokal testen und nur lauffähigen code hochladen!!
last not least: keine diskussion über die ungarische notation! bitte

Sylence · **Verfasst:** 31.08.2007, 15:02

frodenius hat geschrieben:

[*]die einrückung beträgt 4 leerzeichen (kein tabulator)

Das ist doch total abartig und speicherverschwendung und dauert m.E. viel zu lange.
Wenn man durchgehend nur Tabluatoren benutzt, dann schadet das der lesbarkeit kein bisschen.

Aber der Rest ist sinnvoll und sollte auch so verwendet werden.
Du hättest auch einfach sagen können, dass die Irrlicht Coding Rules gelten

thephoenix · **Verfasst:** 31.08.2007, 15:20

Also teilweise kann ich dem nicht gerade zustimmen...

Zu den Whitespaces:
Tabs zum Einrücken, Leerzeichen zum Formatieren, nach Möglichkeit Begrenzung auf ~100 Zeilen (80 ist ein bisschen wenig, ich denke, niemand benutzt hier nen Konsoleneditor):

Code:

int thisIsAVeryLongFunction(int param1,
                                              int param2,
                                              int param3)
{
<TAB>funktion1();
<TAB>if(a)
<TAB>{
<TAB><TAB>function2();
<TAB>}
}

Zitat:

{ und } kriegen eine eine eigene zeile außer es tut der übersichtlichkeit keinen abbruch, wie zb bei }else{

Warum die Ausnahme? Den Klammern grundsätzlich eine eigene Klammer zu geben ist konsistenter und einfacher zu lesen.

Zitat:

jede datei kriegt einen head-comment

Der braucht dann auch eine einheitliche Form. Autor, Copyright und Lizenz etc gehören auch rein.

Zitat:

nur klassen-deklaration im header, KEINE definition!! selbst inline-funktionen! (ausnahme: leere funktionen, wie zb destruktoren)

Sry, wenn das jetzt nicht stimmt, aber: afaik benötigen manche Compiler zum inlinen die Definition sofort, und zumindest, wenn Teile als Library ausgelagert werden, ist das auch notwendig.
Dazu kommen natürlich auch Templates.

Zitat:

späte variablen-deklaration. erst wenn man sie braucht.

imho von Fall zu Fall nicht unbedingt sinnvoll. Zumindest ist es oft übersichtlicher, am Beginn eines Codeblocks alle darin enthaltenen Variablen aufgelistet zu haben.

Zitat:

namen für funktionen und variablen fangen klein an, für klassen, aufzählungen, strukturen groß

Das muss noch weiter spezifiziert werden.
Das da benutze ich in meinem Code vorzugsweise:
thisIsAFunction();
class ClassName;
int thisisavariable; // Unterstriche sind hier bei längeren Namen sinnvoll
enum ESomeEnum
{
ESE_ValueOne = 0,
ESE_ValueTwo
}

Zitat:

überhaupt const am besten ständig verwenden

Wenn man zu viele consts hat, macht man imho etwas falsch

Zitat:

Das ist doch total abartig und speicherverschwendung und dauert m.E. viel zu lange.

Gerade die Argumente sind imho nebensächlich. Dauert zu lange? Ein gescheiter Editor regelt das. Speicherverschwendung? Die paar Bytes?
Wichtiger ist imho, dass jeder mit Tabs seine eigene Tab-Breite einstellen kann. Deswegen sollten imho Leerzeichen nur für darüber hinausgehende Formatierung sein.

Sylence · **Verfasst:** 31.08.2007, 15:45

thephoenix hat geschrieben:

Zitat:

späte variablen-deklaration. erst wenn man sie braucht.

imho von Fall zu Fall nicht unbedingt sinnvoll. Zumindest ist es oft übersichtlicher, am Beginn eines Codeblocks alle darin enthaltenen Variablen aufgelistet zu haben.

naja... Stroustrup schreibt, dass variablen erst dann deklariert werden sollten, wenn sie benutzt werden

thephoenix hat geschrieben:

Zitat:

Das ist doch total abartig und speicherverschwendung und dauert m.E. viel zu lange.

Gerade die Argumente sind imho nebensächlich. Dauert zu lange? Ein gescheiter Editor regelt das. Speicherverschwendung? Die paar Bytes?
Wichtiger ist imho, dass jeder mit Tabs seine eigene Tab-Breite einstellen kann. Deswegen sollten imho Leerzeichen nur für darüber hinausgehende Formatierung sein.

aus den paar bytes können schnell mal ein paar kilobyte/megabyte werden... wir reden hier schließlich von min. 4 bytes pro zeile... und ich denke nicht, dass ein größeres projekt unter 10.000 zeilen bleiben wird...
und für die lesbarkeit des codes spielt es keine rolle, ob da jetzt 4 leerzeichen stehen, oder ein tab, dass vom editor als 3 leerzeichen interpretiert wird.
wenn irgendwelche ascii zeichnungen im spiel sind, dann sind leerzeichen ja sinnvoll, aber ich sehe einfach keinen sinn darin, anstatt einmal auf tab zu hämmern 4mal auf space zu drücken...

oder hättest du lust sowas mit leerzeichen zu formatieren

Code:

function()
{
    if()
    {
         for()
         {
              // gaaanz langer code der jedes mal mit 14(!!!) leerzeichen eingerückt werden muss
         }
    }
}

allein dieser kleine pseudo code würde 33bytes "zuviel" verbrauchen

EDIT:
grrr... ich sollte mal wieder mehr schlafen... mir is grad aufgefallen, dass man ja bei der autoeinrückung einstellen kann, obs tabs oder leerzeichen sein sollen -.-*
Aber mir bleibt der sinn dabei trotzdem schleierhaft

thephoenix · **Verfasst:** 31.08.2007, 15:49

Zitat:

aber ich sehe einfach keinen sinn darin, anstatt einmal auf tab zu hämmern 4mal auf space zu drücken...

Ich denke, alle guten Editoren lassen sich in die Richtung umstellen (ich benutze gedit, der erkennt sogar automatisch, welchen Tabstil er in der derzeitigen Datei benutzen soll, installiert habe ich hier auch noch kate, das rückt bei Wunsch sogar komplett automatisch ein, da sollte es ähnlich mächtige Programme für Windows geben). Übrigends glaube ich auch kaum, dass die Codegröße auch mit Leerzeichen so groß werden wird, dass sie ein größeres Problem darstellen wird. Natürlich wird der Code unnötig aufgebläht, aber problematisch isses wohl noch nicht.

Sylence · **Verfasst:** 31.08.2007, 16:00

thephoenix hat geschrieben:

Natürlich wird der Code unnötig aufgebläht, aber problematisch isses wohl noch nicht.

eben unnötig

Also wenns nach mir gehen würde: tabulatoren

JDHunter · **Verfasst:** 31.08.2007, 18:25

Ich muss mich mal kurz einmischen :lol:

Auch wenn ich ZehScharper bin und von C++ Editoren nicht viel weiß.
Kann ich mir doch aber vorstellen das es bei euch, auch die Option gibt Tabulatoren mit Leerzeichen auffüllen...?!
So kann jeder von euch, die Tab weiter benutzten und es sind aber Lerrzeichen drin!

thephoenix · **Verfasst:** 31.08.2007, 19:15

Zitat:

Kann ich mir doch aber vorstellen das es bei euch, auch die Option gibt Tabulatoren mit Leerzeichen auffüllen...?!
So kann jeder von euch, die Tab weiter benutzten und es sind aber Lerrzeichen drin!

Davon reden wir ja gerade :p
Genau das möchte ich aber nicht, ich möchte schon Tabs in den Dateien drin haben und keine Leerzeichen...

frodenius · **Verfasst:** 31.08.2007, 19:25

jaja also tabulatoren.. ich mein ja nur das bei einer "offiziellen" darstellung des codes der tabulator 4 zeichen entsprechen sollte..

Zitat:

Warum die Ausnahme? Den Klammern grundsätzlich eine eigene Klammer zu geben ist konsistenter und einfacher zu lesen.

ok abgesehn davon das der satz widersinnig ist, versteh ich trotzdem was du meinst ;D und bin dafür.

Zitat:

Der braucht dann auch eine einheitliche Form. Autor, Copyright und Lizenz etc gehören auch rein.

is klar, kennt wer ein gutes format?

Zitat:

Sry, wenn das jetzt nicht stimmt, aber: afaik benötigen manche Compiler zum inlinen die Definition sofort, und zumindest, wenn Teile als Library ausgelagert werden, ist das auch notwendig.
Dazu kommen natürlich auch Templates.

also das ist schon richtig nur ist das kein problem weil man das sowieso so schreibt:

Code:

class SomeClass
{
public:
    SomeClass(int sd);
    inline int getData(){return someData;} //so eben nicht
    int getData2(); //sondern so
private:
    int someData;
};
inline SomeClass::SomeClass(int sd):someData(sd)
{
}
inline int  SomeClass::getData2()
{
    return someData;
}

Zitat:

Du hättest auch einfach sagen können, dass die Irrlicht Coding Rules gelten

wusste nicht wo die zu finden sind und obs die überhaupt gibt..

thephoenix · **Verfasst:** 31.08.2007, 19:38

Zitat:

ok abgesehn davon das der satz widersinnig ist, versteh ich trotzdem was du meinst ;D und bin dafür.

Owned. -.-

Zitat:

nur klassen-deklaration im header, KEINE definition!! selbst inline-funktionen! (ausnahme: leere funktionen, wie zb destruktoren)

Das schließt ursprünglich sowas halt in den Headern auch aus :p

Zitat:

jaja also tabulatoren.. ich mein ja nur das bei einer "offiziellen" darstellung des codes der tabulator 4 zeichen entsprechen sollte..

Akzeptiert

Zitat:

Du hättest auch einfach sagen können, dass die Irrlicht Coding Rules gelten

Das hatte ich komplett überlesen... wie ist es dann von wegen eingeschränkter ungarischer Notation?
(CClass, IInterface, EEnum etc)
Ich persönlich würde zumindest das C bei den Klassen weglassen, dass es eine Klasse ist, kann man dann ja an der Schreibweise sehen (erster Buchstabe groß = Klasse/Struct), ich finde das C einfach hässlich. Die Enums sind da imho eher eine Ausnahme, da sie mit dem Rest ja recht wenig zu tun haben.
Ist was, worüber man sich streiten kann, aber da muss auch eine einheitliche Regelung her.

Zitat:

is klar, kennt wer ein gutes format?

Wie wärs ungefähr damit:

Code:

/*
Copyright (C) <Jahr> <Autor>
Teile (C) <Jahr> <zusätzlicher Autor>

<Lizenzhinweis... was wird das eigentlich für eine Lizenz?>
*/

/*
<Dateiname>

<Beschreibung>
zB.:
Basisklasse mit einigen Funktionen für xy.
*/

Ansonsten sollte alles, was hier entsteht, in eine Datei ins SVN...

frodenius · **Verfasst:** 31.08.2007, 19:53

lizenz..
gute frage...
wollen wir ne art gpl oder so? in etwa dass jeder den code verändern darf aber nur im rahmen des projekts..?

psyco001 · **Verfasst:** 31.08.2007, 20:01

ja das wird wohl das beste sein
^^

coding conventions

Wer ist online?