Willkommen auf dem Portal für Mediengestalter
|
|
Autor |
Nachricht |
Bonestruca
Threadersteller
Dabei seit: 24.06.2002
Ort: S // KÜN
Alter: 37
Geschlecht:
|
Verfasst Sa 15.01.2005 20:30
Titel Guter Programmierstil |
|
|
Buh,
zählt mal bitte alle Eigenschaften auf, die ein "guter und sauberer Programmierstil" eurer Meinung nach enthält.
Danke
Zuletzt bearbeitet von Sarky am So 16.01.2005 12:25, insgesamt 1-mal bearbeitet
|
|
|
|
|
dastef
Dabei seit: 03.11.2003
Ort: -
Alter: -
Geschlecht:
|
Verfasst Sa 15.01.2005 20: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.
|
|
|
|
|
Anzeige
|
|
|
Waschbequen
Account gelöscht
Ort: -
|
Verfasst Sa 15.01.2005 20:51
Titel
|
|
|
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.
|
|
|
|
|
smile jamaica
Dabei seit: 31.10.2003
Ort: Freiburg
Alter: 39
Geschlecht:
|
Verfasst Sa 15.01.2005 21:36
Titel
|
|
|
ich würd ein fach sagen:
- oop wenn möglich
- kommentieren
- einstellungen leicht verwaltbar
- auf funktionierenden klassen aufbauen
|
|
|
|
|
Account gelöscht
Ort: -
Alter: -
|
Verfasst Sa 15.01.2005 22: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.)
http://www.pear.php.net/manual/en/standards.php
|
|
|
|
|
donnerchen
Dabei seit: 06.04.2003
Ort: -
Alter: 53
Geschlecht:
|
Verfasst So 16.01.2005 10:30
Titel
|
|
|
Also, in Sachen Programmierstil kann ich nur dieses Buch hier empfehlen:
Besser PHP programmieren
Das ist echt klasse...
|
|
|
|
|
dastef
Dabei seit: 03.11.2003
Ort: -
Alter: -
Geschlecht:
|
Verfasst So 16.01.2005 12:15
Titel
|
|
|
joar .. und weil ich das auch hab - aber schon mal gelesen verkauf
ich's auch gibt's bei amazon als gebraucht oder direkt bei mir
Und weil wir grad dabei sind .. bissel was zum Thema gefunden
"PHP und Programmierstil" http://www.tutorials.de/tutorials141026.html
Zuletzt bearbeitet von dastef am So 16.01.2005 12:15, insgesamt 1-mal bearbeitet
|
|
|
|
|
Sarky
Dabei seit: 29.06.2002
Ort: Düsseldorf
Alter: 42
Geschlecht:
|
Verfasst So 16.01.2005 12: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.
Konstanten
Konstanten werden komplett groß geschrieben:
Code: |
#define MAX_PLAYER_AMOUNT 2
#define SERVER_TIMEOUT 15
|
Schleifen-Zähler
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)
|
Kurz-Operatoren
Falsch:
Code: |
array[++i] = j;
array[i++] = k;
|
Richtig:
Code: |
i++;
array[i] = j;
array[i] = k;
i++;
|
|
|
|
|
|
|
|
|
Ähnliche Themen |
[php] Programmierstil: PHP Code Abgrenzung
Guter Onlineshop - Empfehlungen?
guter günstiger eShop gesucht
Guter PHP-Code = Schlechtes HTML?
guter sinnvoller flash decompiler gesucht
Powerpoint zu DVD (mov Datei in guter Qualität zu iDVD)
|
|
|
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.
|
|