Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

1

31.10.2012, 21:06

Forenprojekt - Code Konvention

Hier mal zum Debatieren ein paar Vorschläge für den Programmierstyle

1. Allgemein

1.1 Zeilenlänge
Version 1: maximal 80 Zeichen pro Zeile
Version 2: maximal 100 Zeichen pro Zeile

1.2 Einrückweite
Version 1: Einrückweite 3
Version 2: Einrückweite 4
Version 3: Einrückweite 5

2. Namens Konvention:
2.1 Defines
  • Grundsätzlich groß geschrieben
  • ggf. mit Unterstrich

C-/C++-Quelltext

1
2
3
4
5
#define PI 3.14
// oder
#define HEADER_H
// oder
#define MEHR_ALS_EIN_WORT_DEFINE


2.2 Konstanten
  • Grundsätzlich groß geschrieben
  • ggf. mit Unterstrich

C-/C++-Quelltext

1
2
3
const double PI = 3,14159265;
// oder
const int QUADRAT_VON_ZWEI = 4;


2.3 Klassennamen
Version 1:
  • Im style der PascalCase-Regel

C-/C++-Quelltext

1
2
3
class GameEngine
{
};


2.4 Variablen
Version 1:
  • Im style der PascalCase-Regel

C-/C++-Quelltext

1
int BallGeschwindikeit

2.5 Klassenmember
Version 1
  • unterscheidung von Public und Private Member
  • Im style der PascalCase-Regel für Public Member
  • Kleinschreibung von Private Member

C-/C++-Quelltext

1
2
3
4
private:
int ball;
public:
int BallGeschwindigkeit;


Version 2
  • Keine unterscheidung von Public und Private Member
  • Im style der PascalCase-Regel für alle Member

C-/C++-Quelltext

1
2
3
4
private:
int Ball;
public:
int BallGeschwindigkeit;


Version 3
  • Keine unterscheidung von Public und Private Member
  • Im style der PascalCase-Regel für alle Member
  • Member bekommen Prefix m_

C-/C++-Quelltext

1
2
3
4
private:
int m_Ball;
public:
int m_BallGeschwindigkeit;

2.5 Klassenmethoden Schreibweise
Version 1
  • Im style der PascalCase-Regel

C-/C++-Quelltext

1
int BerechneBallPosition();

Version 2
  • mit Unterstrich zwischen einzelnen Worten
  • neue Worte fangen Groß an

C-/C++-Quelltext

1
int Berechne_Ball_Position();

Version 3
  • mit Unterstrich zwischen einzelnen Worten
  • alles klein geschrieben

C-/C++-Quelltext

1
int berechne_ball_position();

2.5 Klassenmethoden Parameter Schreibweise
Version 1
  • Solange Max Zeilenlänge nicht überschritten ist, Parameter hintereinander

C-/C++-Quelltext

1
int Funktion(int Var1,int Var2,float Var3);

Version 2
  • Parameter untereinander
  • Typ und Parametername direkt nach einander

C-/C++-Quelltext

1
2
3
int Funktion(int Var1,
             int Var2,
             float Var3);

Version 3
  • Parameter untereinander
  • Typ unter Typ und Parametername unter Parametername

C-/C++-Quelltext

1
2
3
int Funktion(int   Var1,
             int   Var2,
             float Var3);

3. Einrücken
3.1 Geschweifte Klammern
Version 1
  • Nach jeder geschweiften Klammer auf '{' Einrücken
  • mit einer Tab länge x (Siehe 1.2)
  • Nach jeder geschweiften Klammer zu '}' zurück Einrücken

C-/C++-Quelltext

1
2
3
4
while(1)
{
     // Code
}

Version 2
  • Nach jeder geschweiften Klammer auf '{' Einrücken
  • mit x (Siehe 1.2) space
  • Nach jeder geschweiften Klammer zu '}' zurück Einrücken

C-/C++-Quelltext

1
2
3
4
while(1)
{
     // Code
}

Version 3
  • Nach jeder geschweiften Klammer kein Einrücken

C-/C++-Quelltext

1
2
3
4
while(1)
{
// Code
}

3.2 Case und break
Version 1
  • Nach jedem Case Einrücken
  • mit einer Tab länge (5)
  • Nach jedem break zurück Einrücken

C-/C++-Quelltext

1
2
3
case 'a'
     // Code
break;

Version 2
  • Nach jedem Case Einrücken
  • mit 5 space
  • Nach jedem break zurück Einrücken

C-/C++-Quelltext

1
2
3
case 'a'
     // Code
break;

Version 3
  • Kein Einrücken nach Case

C-/C++-Quelltext

1
2
3
case 'a'
// Code
break;


4. Logische Ausdrücke
4.1 Schreibweise
Version 1
  • Ausdrücke und Operanden Hintereinander weg

C-/C++-Quelltext

1
if(i!=1)

Version 2
  • Ausdrücke und Operanden getrennt mit einem Space

C-/C++-Quelltext

1
if(i != 1)


4.2 Mehrere Logische Ausdrücke
Version 1
  • In einer Zeile
  • nach 4.1 Version 1 oder 2

C-/C++-Quelltext

1
if(i!=1 || i==2)

Version 2
  • Pro Ausdruck eine Zeile
  • nach 4.1 Version 1 oder 2

C-/C++-Quelltext

1
2
if(i!=1 ||
   i==2)


So soll erstmal reichen (Nach mehr als einer Stunde). Es gibt mit Sicherheit noch andere Vereinbarungen die Fehlen, diese werde ich dann Nachtragen und hier aktuell halten. Bitte denkt dran dieser Thread soll nicht alle möglichen Schreibweisen auflisten sondern dazu dienen uns auf einen (minimal) Standard zu einigen.
Wer aufhört besser werden zu wollen hört auf gut zu sein!

aktuelles Projekt:Rickety Racquet

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Koschi« (02.11.2012, 06:55)


idontknow

unregistriert

2

31.10.2012, 22:01

Wäre dagegen public/private Member unterschiedlich zu schreiben! Das verwirrt doch nur und ich würde es als störend empfinden.

Yannic

unregistriert

3

31.10.2012, 22:03

Ist die Länge von einem Tabulator nicht normalerweise 4 Leerzeichen?

idontknow

unregistriert

4

31.10.2012, 22:10

Kommt darauf an, dass kann man bei manchen Programmen einstellen! Bei Visual Studio lohnt es sich imo einzustellen, dass VS statt einem TAB X Leerzeichen macht. Damit beugt man auch vielen Formatierungsproblemen entgegen wenn man den Code woanderst postet.

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

5

01.11.2012, 03:25

C++ ist zwar nicht Python, wo Unterschiede in der Einrückung die Bedeutung des Programmes verändern können, aber es ist imo wichtig, sich entweder auf Tabs oder auf Leerzeichen zu einigen und einen Mix unbedingt zu vermeiden. Denn ein Mix aus Tabs und Leerzeichen wird in mindestens jedem zweiten Editor zu reinem Wortsalat. Und da Tabs oft von zu grober Granularität sind, sind Leerzeichen imo die einzig vernünftige Variante...

Die Verwendung von Makros sollte imo auf das nötigste beschränkt werden, Konstanten sollten niemals als Makros realisiert sein...

6

01.11.2012, 15:13

Ich wäre dafür, dass jeder noch andere Versionen vorschlagen kann, und dass dann in ein paar Tagen eine Umfrage zu jedem Punkt gemacht wird. Dann nimmt man jeweils die Version mit den meisten Stimmen.

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

7

01.11.2012, 15:17

Können wir gern machen, ihr dürft euren Input dann im entsprechenden Vorschlags-Dokument einkippen. Allerdings wäre es schön, wenn nicht jeder mit einer anderen Idee kommt, man muss sich bei einem Team-Projekt immer auf Kompromisse einigen.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

8

01.11.2012, 15:23

Ich denk ein Wiki wäre für sowas das ideale Medium...

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

9

01.11.2012, 15:44

Ist es auch und ist geplant. Es wäre nur schön, wenn die Leute, die mitmachen, entsprechend bis zum Meeting warten könnten und die, die nicht mitmachen, ihre Vorschläge etwas zügeln könnten, denn im Moment entsteht hier nur unnötig Chaos über Dinge, die schon längst geplant sind.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

babelfish

Alter Hase

Beiträge: 1 222

Wohnort: Schweiz

Beruf: Informatiker

  • Private Nachricht senden

10

01.11.2012, 22:32

PascalCase finde ich allgemein toll, bin auch gegen 'm' oder sonstiges vor Klassenmember, weil ein gut gewählter Name meiner Meinung nach schon genug aussagt. Keine Einrückung nach Klammern oder case ist IMHO einfach nur unübersichtlich. Ich finde 2 bis max. 3 Leerzeichen reichen völlig aus, mit 5 hat man die maximale Zeilenlänge zu schnell erreicht.
Wo ich gerne unterscheide sind KlassenMember (PascalCase) und lokale_variablen (klein_mit_underscore).

Werbeanzeige