Programmierstil

[peschmae]

Nein, ich hab das gegenteilige Problem: Zu viele Ideen und zu wenig Manpower.

Das ist nur eine gut getarnte besonders hinterhältige Variante des ursprünglichen Problems

MfG Peschmä

[anda_skoa]

Steigert das die Lesbarkeit? In diesem Fall wuerde ich das Ergebnis schon mit 0 vergleichen.

Ich mache auch immer konkrete boolsche Ausdrücke daraus, ist IMHO besser lesbar (Prüfung ob der Teilungsrest 0 ist, nicht ob der Teilungsrest "gültig" ist) und lässt sich zweitens leichter in andere Sprachen übertragen, die das vorraussetzen (zB Java)

Das ist nur eine gut getarnte besonders hinterhältige Variante des ursprünglichen Problems

Ich glaube das ist die nächste Stufe

Ciao,
_

[davidbaumann]

Mastermind wäre ne gute idee...
Ich versteh das net ganz, euren Schreibstil, ich schreib lieber gut lesbar ausserdem kann ich das mit den ganzen Abkürzungen und so net :-)

Baumi

[axeljaeger]

Bei x == true kann man das nicht nur weglassen, man sollte sogar und zwar aus folgendem Grund: Der Vergleichsoperator (==) ist ja an sich auch nur eine Funktion. Der Rückgabewert dieser Funktion ist vom Typ bool. Man darf ja auch sowas schreiben

bool b = x == 5;

Wenn man also ein bool nochmal durch eine Funktion jagt, die wo ein bool rauskommt, ist das doppelt gemoppelt.

[peschmae]

Da es hier um Stil geht würde ich doch Klammern setzen. Das macht das Dingens dann wohl ein bisschen lesbarer.

MfG Peschmä

[Trillian]

Im Linux-Kernel wird AFAIK auch mit Spaces anstelle von Tabs gearbeitet.

Im CodingStyle Text steht drin:
"Tabs are 8 spaces [...]."

Diese Aussage macht keinen Sinn, wenn man \t statt ' ' nimmt :]

=> Tabs > Spaces

[chrizel]

Im CodingStyle Text steht drin:
"Tabs are 8 spaces [...]."

Hat sich im laufe der Zeit wohl veraendert. Frueher waren es noch Tabs...

[nobody0]

Für Tabs gibt's ja (unter Linux) die Funktionen exand u. unexpand um die Tabs zu eleminieren/einzusezten

Und dem indent kann man dazu auch Optionen mitgeben.
Problematisch ist der indent aber bei Assembler-Code in C-Dateien; da kommt häufig etwas nicht korrekt compilierares raus. Würde der Code in separate Assembler-Dateien gepackt, könnte man den indent auch über die Kernel-Sourcen gehen lassen, aber bei dem Chaos dort geht das nicht problemlos, selbst wenn man von dutzenden unvollständigen Treiber-Dateien absieht.

[BeS]

Hallo,

Bei x == true kann man das nicht nur weglassen, man sollte sogar...

richtig.
Auf der anderen Seite sollte man aber auch bei Vergleichen die keine boolschen Ausdrücke sind es nicht weglassen. So wird es zumindest in vielen style-guides beschrieben und ich denke es ist auch wirklich sinnvoll.

Wenn ich wissen will ob ein Wert > 0 ist, dann ist das eben ein Vergleich und kein boolscher Audruck auch wenn man es in C als sowas sehen kann.
Da liegt es dann aber eben in der Verantwortung des Programmieres nicht alle "Tricks" die C einem bietet auch immer bis aufs letzte auszureizen, denn sonst könnte ein größeres Programm ziemlich schnell ziemlich unübersichtlich und schwer verständlich werden.

Daher sagen wohl die meisten style-guides:

Für
if (x == true)
ist ganz klar
if (x)
die bessere Wahl, da hier eine boolsche Variable ausgewertet wird.

Geht es aber um Vergleiche, wie z.B. a%b > 0, dann ist
if (a%b > 0)
die bessere Wahl und nicht
if ( !(a%b) )

Die Frage war ja nach einem guten Programmierstiel und nicht danach, alles möglichst kurz zu schreiben.

[nobody0]

Geht es aber um Vergleiche, wie z.B. a%b > 0, dann ist
if (a%b > 0)
die bessere Wahl und nicht
if ( !(a%b) )

Das ist falsch;
!(a%b)
bedeutet
(a%b) not_eq 0
und nicht
(a%b) > 0
.

Zur Sicherheit sollte man möglichst iso646.h nehmen, denn & und && können leicht verwechselt werden, aber bitand und and nicht; zudem ist es mit iso646 leichter lesbar.

[BeS]

Das ist falsch;
!(a%b)
bedeutet
(a%b) not_eq 0
und nicht
(a%b) > 0
.

Ok, für ein negatives a könnte der Rest auch negativ werden, ich bin jetzt halt von natürlichen Zahlen ausgegangen.
Das ändert aber nicht an der Grundaussage zum Thema Programmierstiel, dass man den Vergleichsoperator nur weglassen sollte wenn es sich wirklich um eine boolsche Variable handelt.