Setzen von Programmierregeln

[Wilhelm von Preußen]

So lasset uns hier Regeln zusammentragen, mit welchen festen Regeln wir programmieren. Dies soll dazu beitragen, dass Code, den wir untereinander austauschen, allgemein besser verständlich wird. Gar sollten wir versuchen, einheitlichen code zu schreiben. Desweiteren sollte er so verfasst werden, dass man selbst nach einem Jahr sich leicht in den code wieder einarbeiten kann. Ich entsinne mich an ein Praktikum in einer kleinen softwareschmiede in der näheren Umgebung. Dort wurde nach 3 Monaten tag und nacht programmieren ein Projekt abgebrochen, Grund: Unübersichtlichkeit des Quelltextes(100 header + 100 cpp files ). Woran es sicherlich nicht lag, nein, es lag an der mangelnden Kommentierung des Quelltextes!
Hier nun meine Vorschläge:

1. KEINE TYPEDEFS
bsp: typedef unsigned short USHORT

2. Wenns geht stets 32 bit Variablen verwenden anstelle 8 oder 16 bit! ab pentium aufwärts sind alle prozessoren 32bit, heisst daten chunks können einen 32bit prozessor in einigen SItuationen gar verlangsamen!

3. Wenns geht inline funktionen verwenden! Macht zwar grössere Programme aber Speed ist wichtiger. Ausnahme sind wahrlich mächtige Funktionen die vorraussichtlich etliche male aufgerufen werden.

4. Sauberer, gut kommentierter/dokumentierter Code! vorschlag für grösserer Trennungen:

Code: Alles auswählen

/***************************************************/
/*              Hier kommt was neues               */
/***************************************************/

Aus dieser schrecklichen Erfahung beim praktikum weiss ich, dass, wenns geht, jede Zeile kurz kommentiert werden sollte.

5. Kein komplexer code, simpel und leicht zu wartender code ist effektiver. Bsp(dank an andre lamothe )
if((x+=(2*buffer[index++]))>10)
{
mache blabla;
}
besser so:
x += (2*buffer[index]);
index++;

if(x>10)
{
mache blabla;
}
ich weiss, der erste Teil sieht beeindruckender aus, aber die verständlichkeit ist beim zweiten besser(jedenfalls für mich )

6. Keine komplexen Daten Strukturen für einfache Objekte. Bsp keine verkettete liste für einen fixen array mit stets 256 indexes.

7. Einsatz von c++ nur in massen.

8. Glasklare Benennung der files, subfolders für sound, grafiken etc..

meine vorschläge...

[TheEvilForce]

Zu 1)
Wenns denn sein muss...
Zu 2)
Auch das ist in Ordnung...
Zu 3)
Meine vollste Zustimmung...
Zu 4)
Ohje, das wird ein Graus für mich...
Zu 5)
Ich benutze keinen komplexen Code, wirklich...
Zu 6)
Was ist an einer verketteten Liste so komplex? Sind doch Grundlagen, die jeder kennt.
Zu 7)
Einsatz von C++ in Massen find ich super
Zu 8)
Ok, das ist schon klar...

[Wilhelm von Preußen]

Originally posted by TheEvilForce
Zu 1)
Wenns denn sein muss...
Zu 2)
Auch das ist in Ordnung...
Zu 3)
Meine vollste Zustimmung...
Zu 4)
Ohje, das wird ein Graus für mich...
Zu 5)
Ich benutze keinen komplexen Code, wirklich...
Zu 6)
Was ist an einer verketteten Liste so komplex? Sind doch Grundlagen, die jeder kennt.
Zu 7)
Einsatz von C++ in Massen find ich super
Zu 8)
Ok, das ist schon klar...

ich vergass, weitere ideen können selbstverständlich auch vorgetragen werden.

zu 6 nochmal: Ihr würdet eine verkettete liste anstelle eines einfachen arrays mit 256 indexes verwenden? ihr benutzt wirklich keinen komplexen code