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