Dabei seit: 03.11.2003 Ort: - Alter: - Geschlecht:
Verfasst Sa 15.01.2005 21:33 Titel
das kann man nich fix fest machen .. kommentare sind normaler-
weise gut - können aber entsprechend verflechtet ziemlich grauen-
haft sein ..
ansonsten fällt mir noch nen gutes naming der variablen etc ein,
auf jeden fall einrücken. initialisierung der variablen vor ver-
wendung. das wär mal was, was mir auf die schnelle einfällt.
Guter Stil ist Definitionssache, und in jedem Fall abhängig von Umgebung und Sprache. Mit C# und Visual Studio .NET bin ich zum Beispiel in der Lage umfangreiche XML-Kommentare zu verwenden, um daraus dann wieder automatisch ne technische Doku zu generieren. Was den Code selbst angeht kann ich in meiner Page_Load()-Methode aber auch wie in PHP oder ASP rein prozedural runter programmieren, oder aber vernünftig objektorientiert arbeiten. Trotzdem bleibt es Ansichtssache, was je nach Fall nun guter Stil ist...
Grundsätzlich sollte man einfach alle Möglichkeiten nutzen, die einem geboten werden, um:
- die Wartbarkeit von Code zu fördern
- so schnell wie möglich Ergebnisse zu erzielen
Gernerell sind natürlich Sachen wie Einrückungen, vernünftige Kommentierung und Strukturierung sinnvoll. Alles andere hängt wie schon geschrieben auch von den Möglichkeiten ab.
Dabei seit: 25.01.2004 Ort: Mars Alter: - Geschlecht: -
Verfasst Sa 15.01.2005 23:10 Titel
Meist heißt "sauber" ja auch, gewisse Standards einzuhalten, im Falle PHP gibts ja zum Beispiel die Klassensammlung PEAR, die ja ein relativ strenges Regelwerk aufgestellt hat, wie Programmcode auszusehen hat. Ebenfalls unter dem Gesichtspunkt der automatisierten Erstellung von Dokumentationsmaterial (dessen Freund ich zwar nicht bin... naja.)
Dabei seit: 29.06.2002 Ort: Düsseldorf Alter: 30 Geschlecht:
Verfasst So 16.01.2005 13:19 Titel
Coding Style / Richtlinien zur Quelltext Formatierung
Für ein Programmierprojekt im Team habe ich vor einiger Zeit mal "Richtlinien" zum Programmierstil aufgestellt, damit der Code später einheitlich aussieht. Diese enthalten einen Großteil meiner Vorstellungen zu einem sauberen, gut lesbaren Stil.
Der Text ist zwar für C++ geschrieben, aber da es hier allein um die Formatierung des Quelltextes geht, dürfte er dank weitgehend gleicher Syntax auch für PHP brauchbar sein:
Richtlinien zum Programmier-Stil (Coding Style) 1. Namenskonventionen
Projektsprache
Die Projekt- und Dokumentationssprache ist Englisch
Einrückungen
Code-Abschnitte werden per Tabulator-Taste immer um 4 Leerzeichen eingerückt.
Variablen / Eigenschaften
Variablen werden eindeutig nach Ihrer Funktion benannt, in zusammengeschriebenen Wörtern:
Code:
bool PlayerActive;
int PlayerScore;
Eigenschaften von Objekten erhalten zudem das Präfix "m_" um von anderen Variablen unterscheidbar zu sein:
Code:
int m_PlayerPosX;
char* m_PlayerName;
Klassen
Klassen wird bei ihrer Deklaration ein großes C vor den Klassennamen gestellt, um sie von Variablen unterscheiden zu können.
Code:
/**
My nice little example class
Doing nothing special ;-)
@author Horst Horstmann
@see CMyGame
*/
class CMyClass
{
private:
// just an integer
int m_Foo;
protected:
// example string
char* m_Bar;
public:
// default constructor
CMyClass();
// default deconstructor
~CMyClass();
};
Reihenfolge der Zugriffsrechte: Erst private, dann protected, dann public. Innerhalb der Zugriffsabschnitte erfolgt zuerst die Deklaration aller Member-Variablen, dann die der Methoden. get() und set() Methoden sind ebenfalls in eigene Blöcke zu unterteilen.
Jede Klasse ist zudem ausführlich zu kommentieren mit Beschreibung der Funktion, eventuellen Verweisen auf weitere Klassen im unmittelbaren Umfeld und dem Autor.
Variablennamen mit nur einer Stelle sind nur in Schleifen erlaubt. Die äußerste Schleife erhält den Index i, innere Schleifen setzen sich mit j, k... fort. Beispiel:
Code:
for (i = 0; i < OuterSize; i++)
{
for (j = 0; j < InnerSize; j++)
{
foo(i, j);
}
}
Funktionsnamen / Methodennamen
Basierend auf der Funktionsnamen-Vergabe der Irrlicht Engine wird camelCase verwendet, d.h. Funktionsnamen werden wie in Java benannt:
Code:
printLoginStatus();
getUserData();
Falsch:
Code:
PrintLoginStatus();
get_user_data();
Funktionsparameter / Methodenparameter
Der Zweck des Parameters soll bereits anhand des Namens erkennbar sein. Zudem erhalten alle Parameter das Präfix "p_" um von anderen Variablen unterscheidbar zu sein
Code:
void loadSprite(char* p_FileName, const int p_x, const int p_y);
int setGameState(const int p_GameState);
Keine "Magic Numbers"
Werden Zahlen zur Identifikation verwendet wie z.B. bei GUI-Elementen, so sind diese Identifikatoren als Konstanten bzw. Enums zu erklären.
Falsch:
Code:
createButton("Hallo", 10, 10, 100);
Richtig:
Code:
enum eGUIElements
{
GUI_BUTTON_HALLO
};
createButton("Hallo", 10, 10, GUI_BUTTON_HALLO);
2. Code Layout
Klammern immer setzen
Falsch:
Code:
if (condition) do_stuff();
if (condition)
doStuff();
while (condition)
doStuff();
for (i = 0; i < size; i++)
doStuff(i);
Richtig:
Code:
if (condition)
{
doStuff();
}
while (condition)
{
doStuff();
}
for (i = 0; i < size; i++)
{
doStuff();
}
Klammer-Positionen
Klammern stehen immer alleine in einer einzelnen Zeile auf der Höhe des vorhergehenden Codeblocks, der darauf folgende wird um einen Tabulator eingerückt.
Code:
if (condition)
{
while (condition2)
{
...
}
}
else
{
...
}
for (i = 0; i < size; i++)
{
...
}
while (condition)
{
...
}
void doStuff()
{
...
}
Leerzeichen zwischen Tokens
Falsch:
Code:
i=0;
if(i<7) ...
if ( (i < 7)&&(j > 8) ) ...
doStuff( i, "foo", b );
for(i=0; i<size; i++) ...
i=(j < size)?0:1;
Richtig:
Code:
i = 0;
if (i < 7) ...
if ((i < 7) && (j > 8)) ...
doStuff(i, "foo", b);
for (i = 0; i < size; i++) ...
i = (j < size) ? 0 : 1;
Operatoren-Reihenfolge
Um Logikfehler zu vermeiden sind immer Klammern bei logischen Operationen aller Art zu setzen.
Falsch
Code:
bool = (i < 7 && j > 8 || k == 4);
Richtig
Code:
bool = ((i < 7) && ((j < 8) || (k == 4)));
Kommentare
Kommentare sind immer und ausführlich zu setzen und immer in einer eigenen Zeile, keine Vermischung mit Code.
Falsch:
Code:
doStuff(); // do some stuff
Richtig:
Code:
// do some stuff
doStuff();
Komplexere Anweisungen sind in einzelne Blöcke zu unterteilen:
Code:
//-------------------
// connect to server
//-------------------
if (!serverConnect(ServerIP))
{
....
}
else
{
....
}
//-----------------
// initialize game
//-----------------
....
Jede Methode und Funktion ist für die Dokumentation mittels Doxygen im Stil von JavaDoc zu kommentieren:
Code:
/**
* Connect to game server at given address
*
* @param p_ServerAddr is the IP Address of the server (e.g. 192.168.0.1)
* @return 1 if connection successful
* @see serverDisconnect()
* @author Horst Horstmann
*/
int serverConnect(TServerAddr p_ServerAddr)
Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum nicht antworten. Du kannst an Umfragen in diesem Forum nicht mitmachen.
Willkommen auf dem Portal für Mediengestalter
