Coding-Standard

[rand]

Das ist Quatsch.
Vllt. machen das manche Compiler, der Standard schreibt es aber definitiv nicht vor!

Hab jetzt leider auf die Schnelle den Standard nicht online gefunden, nur einen Draft, aber die sollten sich in dem Punkt nicht unterscheiden.

All identifiers that begin with an underscore and either an uppercase letter or another
underscore are always reserved for any use.

(nicht ohne Grund heißen z.B. die neuen C99-Typen _Bool und _Complex).

Also bleibe ich dabei, die Strukturbezeichnungen sind ungünstig.

Bei dem Rest hast du aber Recht, das wichtigste ist Einheitlichkeit im Proramm.

[-[RiDER]-]

Hab jetzt leider auf die Schnelle den Standard nicht online gefunden, nur einen Draft, aber die sollten sich in dem Punkt nicht unterscheiden.

All identifiers that begin with an underscore and either an uppercase letter or another
underscore are always reserved for any use.

Tatsächlich, Du scheinst Recht zu haben: Bezeichner (und typedefed Types sind solche identifier), die mit Unterstrich beginnen, dem ein Großbuchstabe oder ein weiterer Unterstrich folgt, sind für die Standardbibliothek reserviert.

(nicht ohne Grund heißen z.B. die neuen C99-Typen _Bool und _Complex).

Gut, das wären zwei Schlüsselwörter - daraus ließe sich keine Regel ableiten (so wie uint64_t kein Schlüsselwort ist und dennoch als Bezeichner ausscheidet, da er Teil der Standardbibliothek ist).

Also bleibe ich dabei, die Strukturbezeichnungen sind ungünstig.

Sehr richtig, sehe ich jetzt auch so!
Die meisten Compiler werden derartige Bezeichner zulassen, der Standard schreibt aber undefined behavior vor und nach dem muss man sich wohl richten, wenn man nicht einen konkreten Compiler diskutiert.

Vllt. sollte man dem Verlag oder Autoren schreiben - von Donald E. Knuth jedenfalls würde man dafür 16^2 Cent kriegen

GreetZ RiDER

[Cheese]

lächerlich das es sich jemand anmaßt nen standard für sowas festlegen zu dürfen o.O

kommentare nur mit "//"?
irgendwie glaub ich mich zu erinnern in jedem robusten programm (feste GNU/Linux sachen) bevorzugt die benutzung von /* .. */ gesehen zu haben,
oder die sache mit den klammern, z.b. benutzt der linux kernel:
int function()
{
[TAB] blub;
}


es ist einiges wichtiger darauf zu achten das im gesammten projekt ein einheitlicher stil festgelegt wird und das man mit diesem selbst/das team gut arbeiten kann.

[blackberry]

Cheese und seine Code-Anarchie...
Was mich betrifft, so würde ich mich durchaus freuen, wenn sich einige, die hier in der C/C++ Section nach Hilfe fragen den Code der einem manchmal "vorgeworfen" wird etwas strikter formatiert hätten.

[_MrKode]

Cheese hat die Intention wohl nicht so ganz verstanden. Der FP sagt nichts weiter aus, dass man sich bei der Codeformatierung an gewisse Regeln halten sollte und diese Regeln auch durch das komplette Projekt umsetzen sollte. Für das Buch ist die Formatierung gemäss des FPs. Wie du deine Projekte gliederst interessiert den Autoren wohl einen feuchten Chillischiss. Trotzdem wirst auch du lernen, dass gewisse vorgegebene Regeln die Zusammenarbeit in einem Team gewaltig vereinfachen können (nicht umsonst haben die ganzen OSS Projekte jeweils ziemlich strikte Regeln bezüglich der Formatierung, des Commitens und anderen basischen Vorgängen im Programmieralltag).

So nebenbei: Python kann man sehr wohl auch mit Leerzeichen einrücken, nur müssen die einzelnen "Einrückungsschritte" gleichbleibend sein (1 Einrückung = 4 Spaces oder sonst 2 Spaces oder sont 8 Spaces whatever, nicht: 1 Einrückung = 2 oder 4 oder 8 Spaces).