Programmierstil

[davidbaumann]

Hab grad mein erstes Programm fertig gestellt, wollt nur mal wissen was ihr von dem Programmierstil haltet:


#include <iostream>
using namespace std;

int main()
{
// --> alle Variablen

int minzahl,maxzahl; // lol self-explaining
int p; //var in Hauptschleife
int t; // var in Testschleife
bool kt; // kt == kein Teiler

//eingabe
cout << "Bitte geben sie die kleinere Zahl an: ";
cin >> minzahl;

cout << "Bitte geben sie die groesste Zahl an: ";
cin >> maxzahl;

//ueberpruefung
if(!(maxzahl>=minzahl))
{
cout << "Zahlen nicht gueltig\n";
system("PAUSE");
return 0;
}

//berechnung


// --> Hauptschleife
for(p=minzahl; p <= maxzahl; p++)
{
t = 2;
kt = true;
// schleife fuer teiler
while((t < p) && (kt == true))
{

if((p%t == 0)) kt = false;
t++;
}
if(kt == true) cout << "zahl " << p << "\t";

}
//ende
cout << "\n\n";
system("PAUSE");
}

Is unter Windows :eek: mit devc++ compiliert, muesste aber auch unter Linux/Unix und so weiter laufen (Standard-Ansi oder so :-))

Mfg,
Masta

[Psycho0815]

Naja bei sonem kurzen code kann man zum programmierstil wenig sagen.
aber wenn ein kommentar nicht nötig ist(self-explaining) dann mach auch keinen.
davon abgesehen bin ich persönlich der meinung das kommentare in englisch seien sollten, aber das ist nur meine unmaßgebliche meinung.

[anda_skoa]

Wenn möglich würde ich dazu raten, bessere Variablennamen zu verwenden, so wie du das schon mit minzahl, maxzahl gemacht hast.
kt ist schlecht

p reicht in der Schleife, generell deklariert man Variablen so eng wie möglich



for (int p = minzahl; p <= maxzahl; p++)


das gefällt mir auch nicht so:


if(!(maxzahl>=minzahl))

besser fände ich


if(maxzahl<minzahl)


Ciao,
_

[panzi]

Und ich würd die Variablen zwecks Fehlervermeidung bei der deklaration gleich initialisieren:

...
int p = 0;
...

Und weiters würd ich nciht system("PAUSE") verwenden, zumal das erstens ein unnötiger Aufruf eines anderen Programmes ist und zweitens OS abhängig ist.

[davidbaumann]

Und ich würd die Variablen zwecks Fehlervermeidung bei der deklaration gleich initialisieren:

...
int p = 0;
...

Und weiters würd ich nciht system("PAUSE") verwenden, zumal das erstens ein unnötiger Aufruf eines anderen Programmes ist und zweitens OS abhängig ist.

Was kann ich da sonst verwendet?
einfach cin; bringt nix...

Und wegen der Variablen:
was heisst kein teiler auf Englisch? no divisor, oder? is zu lang :-)

Jo, eigentlich gehoeren comments und vars in Englisch, mach ich eigentlich meist auch so...

Mfg,
Baumi

PS: hat jemand ne idee was ich so zum spass proggen koennte???
bin noch noob...

[peschmae]

PS: hat jemand ne idee was ich so zum spass proggen koennte???
bin noch noob...

Lol. Das Problem haben alle. :p
Versuchs mal mit einem Mastermind (Ratespiel, kennste doch schon, oder?)

MfG Peschmä

[panzi]

void wait_for_enter( void ) {
std::string str;
std::cout << "Weiter mit ENTER... " << std::flush;
std::getline( std::cin, str );
}

[axeljaeger]

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

[chrizel]

Hier so meine Meinung zum Style...


int minzahl,maxzahl; // lol self-explaining
Mache bitte nach jedem Komma ein Leerzeichen. Also so:

int minzahl, maxzahl;



if(!(maxzahl>=minzahl))
Mache bitte ausreichend Leerzeichen. Also so (incl. der logischeren Version):

if (maxzahl < minzahl)


for(p=minzahl; p <= maxzahl; p++)
Und hinter und vor einem Istgleich immer ein Leerzeichen! Also so:

for (p = minzahl; p <= maxzahl; p++)


while((t < p) && (kt == true))
...
if((p%t == 0)) kt = false;


Am besten ist es wenn man hinter einem if, while und for immer ein Leerzeichen setzt. Das steigert die lesbarkeit. Bei normalen Funktionsnamen ist dies nicht noetig.

Also:

if ((p % t) == 0)

Nicht:

if((p % t) == 0)

Am besten finde ich den Styleguide von VIM. Wenn du dir VIM im Sourcecode runterladest kannst du dir den ja mal angucken. Den finde ich recht passend. Also genau richtige Einrueckung (4 Spaces, keine Tabs) und auch die geschwungenen Klammern richtig gesetzt (if (...) {), ein relativ verbreiteter Stil. (der andere verbreitete waere dieser Microsoft-Style mit der geschwungenen Klammer in einer eigenen Zeile). Die VIM-Guidelines setzen auch das um was ich da oben teilweise kritisiert habe.

GNU-Style find ich in der Einrueckung nicht so gut aber im grunde ist es egal. Linux-Style gefaellt mir nicht so weil dort mit Tabulator eingerueckt wird. (die Erfahrung hat gezeigt auf Tabulator ganz zu verzichten -> nur Leerzeichen) Ist natuerlich alles auch Geschmackssache. Ansonsten ist der Linux-Style auch empfehlenswert. Klammernsetzung etc. gut.

Guckt euch einfach mal ein paar OpenSource-Projekte an. Dort gibt es in den Dokus zum Sourcecode oft Styleguides die gewisse Regeln zur Formatierung vorschreiben.

Es ist nicht so wichtig welchen Stil man unbedingt nimmt. (zumindest auf Einrueckung und geschwungenen Klammern bezogen). Viel wichtiger ist dass man den Stil konsequent durchsetzt und nicht immer im gleichen Projekt wechselt.

Auf die Lesbarkeit (genuegend Leerzeichen!!) sollte man allerdings immer achten.

[nobody0]

if ((p % t) == 0)

Das ist nicht optimal; besser wäre die Konstante auf der Links vom ==, denn dann fäll es dem Compiler sofort auf, wenn man ein Gleichheitszeichen vergisst, also = statt == schreibt.

Außerdem ist es schlechter Stil den Coder per Hand zu Formattieren; da baut man zu leicht Fehler ein und verschwendet Zeit mit Prettyprinting, das ein Prettyprinter wie indent schneller u. zuverlässiger erledigt.

Deshalb nehme ich dafür ein Skript:



#!/bin/bash
for f in *.c ; do
if test -f $f; then
indent --blank-lines-after-procedures \
--line-length160 --continue-at-parentheses \
--dont-cuddle-else --brace-indent0 --space-after-cast \
--blank-before-sizeof --dont-format-comments \
--space-after-procedure-calls --tab-size8 --no-tabs \
--case-indentation2 -ppi 3 $f;
fi
done
...
exit 0


In dem ...-Abscnitt Teste ich noch auf schlechte Funktionen wie malloc, strcmp usw. weil die fast immer durch calloc, strncmp usw. ersetzt werden sollten und zudem werden da noch alle Whitespaces am Zeilenende gelöscht und Tabs in Leerzeichen umgewandelt, damit beim diff nur echte Änderungen angezeigt werden.

[Sym]

@chrizel:
es müssen aber nicht hinter jeden Kommande (if, while, etc...) Leerzeichen stehen. Ich finde, das behindert die Lesbarkeit eher, als dass es sie unterstützt.

[chrizel]

Das ist nicht optimal; besser wäre die Konstante auf der Links vom ==, denn dann fäll es dem Compiler sofort auf, wenn man ein Gleichheitszeichen vergisst, also = statt == schreibt.

Macht Sinn. Ich hasse es aber wenn die 0 als erstes steht. Da passt die erstere Version besser in den Denkvorgang.

Ist es nicht so, dass gcc mit -Wall auch im normalen Fall eine Warnung ausgibt? Muss ich danach mal testen.


@chrizel:
es müssen aber nicht hinter jeden Kommande (if, while, etc...) Leerzeichen stehen. Ich finde, das behindert die Lesbarkeit eher, als dass es sie unterstützt.

Es steigert die lesbarkeit enorm und sieht bei if, while, etc. sogar passend aus. Dabei merkt man dann naemlich auch den Unterschied zwischen einer normalen Funktion und den eingebauten Konstrukten! if und while sind eben nunmal keine Funktionen. Hier macht ein andere Stil durchaus Sinn. Steht uebrigends auch so in den VIM-Guidelines. Ich glaube auch in den Linux-Guidelines aber da bin ich mir nicht so sicher. (aber wie gesagt, Geschmackssache)

[wraith]

if ((p % t) == 0)

Das ist nicht optimal; besser wäre die Konstante auf der Links vom ==, denn dann fäll es dem Compiler sofort auf, wenn man ein Gleichheitszeichen vergisst, also = statt == schreibt.
(p % t) ist kein gültiger LValue, also kann man garnicht = statt == schreiben.

Und ob die Konstante immer links stehen sollte, war schon immer ein Grund für heftige Diskussionen.
Viele empfinden die Inversion als schwerer lesbar, denn dann sollte man diese Schreibweise auch komplett durchziehen und bei Größer/Kleiner-Vergleichen die Konstante nachlinks schreiben.


In dem ...-Abscnitt Teste ich noch auf schlechte Funktionen wie malloc, strcmp usw. weil die fast immer durch calloc, strncmp usw. ersetzt werden sollten

malloc durch calloc ersetzen?
Nene, calloc angewendet um Speicher für ein Datentypen ungleich (unsigned) char ist undefiniert.
Was ist wenn z.b int Paddingbits hat?

[axeljaeger]

if ((p % t) == 0)
Sowas würde ich in C++ ganz lassen. Weil in C++ alles ungleich 0 war ist, lieber sowas machen:


if (!(p % t))

Oder noch besser: Die Bedingung gleich umkehren, so dass man die Klammern und das ! weglassen kann.

Und sowas gehört erst recht verboten:

if (kt == true)


[/code]

[chrizel]

Sowas würde ich in C++ ganz lassen. Weil in C++ alles ungleich 0 war ist
In C auch. ;)



lieber sowas machen:


if (!p % t)

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



Und sowas gehört erst recht verboten:

if (kt == true)

Ja, da kann mans weglassen.

Man muss halt abwaegen zwischen Lesbarkeit und wenig Code... wenig Code ist nicht unbedingt gut lesbarer Code.

[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 :D

[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.