Ich höre seit 1 Woche immer wieder das kein c++ Programier styl so schrecklich ist...
Könntet ihr den mal bewerten?
Bin noch recht noch bei C++

// Aktien.cpp - Programm bzg. Aktien
#include <iostream>
#include <string>
using namespace std;

int main()
{
    string Arbeitsverhaeltnis;
    int Arbeitsdauer;

    cout << "Befinden Sie sich in einem gekuendigtem Arbeitsverhaeltnis?" << endl;
    cin  >> Arbeitsverhaeltnis;

    if(Arbeitsverhaeltnis == "Ja" || Arbeitsverhaeltnis == "ja") 
    {
    cout << "Sie erhalten keine Aktien" << endl;
    }
    else
    {

        cout << "Wie lange arbeiten Sie schon in unserem Betrieb?" << endl;
        cin  >>	Arbeitsdauer;
       }

       if(Arbeitsdauer >=10)	
       {

                        cout << "Sie erhalten Zwanzig Aktien" << endl;
                        system("PAUSE");
                        }

                        if(Arbeitsdauer <=2) 
                        {
                                        cout <<"Sie erhalten keine Aktien" << endl;
                                        system("PAUSE");
                                        }
                                        if(Arbeitsdauer>2 && Arbeitsdauer < 10 )
                                        {
                                                          cout << "Sie erhalten Zehn Aktien" << endl;
                                                          system("PAUSE");
                                                          }

    return 0;
}

Danke für eure Beurteilungen

Naja wenn nicht werde ich den Tip sicher berücksichtigen!

So far,

Style

Außerdem sind deine Einrückungen total seltsam und verwirrend.
So macht man das normalerweise nicht.

Und als letztes vielleicht noch; system("PAUSE") ist immer schlecht!
Gründe, warum das so schlecht ist, kannst du auf ewig vielen Seiten im Netz finden.

Deinen Code könnte ich auf meinem Notebook mit 1024x768 Pixeln gar nicht vernünftig anschauen.

Die schließenden Klammern sind mal total mies gesetzt, da kann man nur raten wo der Block aufhört.

if()
{
  if()
  { 
    if()
    {
      //...
    }
  }
}

Du gehst einfach immer weiter nach rechts. Dabei ist der Sinn und Zweck hinter der ganzen Geschichte doch, dass du auf einen Blick sehen können sollst, wo ein Block beginnt und endet. Dazu muss er auf der glechen Ebene notiert werden. Der Code im jeweiligen Block wird bei dir übrigens manchmal eingerückt (mal mehr, mal weniger ), manchmal aber auch nicht. Da fehlt jede Konsequenz. Ich meine es nicht böse, aber mach dir mal Gedanken darüber. Wenn du größere Programme schreiben willst, ist eine ordentliche Struktur unbedingt notwendig.

P.S.: Wieso darf ich die erste Frage nicht mit "JA" beantworten?

if(Arbeitsverhaeltnis == "Ja" || Arbeitsverhaeltnis == "ja") 
    {
    cout << "Sie erhalten keine Aktien" << endl;
    }
    else
    {
        
        cout << "Wie lange arbeiten Sie schon in unserem Betrieb?" << endl;
        cin  >>	Arbeitsdauer;
       }
       
       if(Arbeitsdauer >=10)	
       {
                       	
                        cout << "Sie erhalten Zwanzig Aktien" << endl;
                        system("PAUSE");
                        }

Nochmal ganz klar: du machst hier einen if-else-Block auf und schließt ihn mit der geschweiften Klammer wieder. Im Anschluss kommt ein weiterer Block, der aber irgendwie eingerückt ist (relativ zum ersten). Das erweckt beim Überfliegen den Anschein, als sei der zweite Block innerhalb des ersten. Und das ist natürlich gefährlich und schadet der Übersicht enorm. Achte einfach darauf, dass Blöcke gleicher Ebene auch so notiert sind.

Der verwendete Stil ist dabei gar nicht so wichtig, als die Konsistenz und Übersichtlichkeit, alle gängigen Stile sind Konsistenz und übersichtlich.

// Ich würde generell Abstände machen zwischen if/while/for und öffnenden Klammern
    // statt
    if(Arbeitsverhaeltnis == "Ja" || Arbeitsverhaeltnis == "ja") 
    // schreibst du:
    if (Arbeitsverhaeltnis == "Ja" || Arbeitsverhaeltnis == "ja")

        // Mit den Leerschlägen solltest du dich konsequent halten
        // dass << und >> auf gleicher Höhe sind, ist jedoch okay
        cout << "Wie lange arbeiten Sie schon in unserem Betrieb?" << endl;
        cin  >>	Arbeitsdauer; // hier z.B. weiter nach vorne

       // bei den Vergleichsoperatoren würde ich generell immer Abstände
       // zwischen Operator und Operanden machen, und zwar auf beiden Seiten
       // statt
       if(Arbeitsdauer >=10)
       // schreibst du:
       if (Arbeitsdauer >= 10)

       // und anstelle von
       if(Arbeitsdauer>2 && Arbeitsdauer < 10 )
       // sieht Folgendes viel besser aus:
       if (Arbeitsdauer > 2  &&  Arbeitsdauer < 10) // (oder auch nur 1 Leerschlag bei &&)

Styler2008 schrieb:

Oha anscheinend habe ich noch viel in Sachen Styl zu lernen O.o und ich war immer so überzeugt das er gut ist

Scheinbar nicht, sonst hättest du diesen Thread nicht aufgemacht

Styler2008 schrieb:

Styl

Wenn schon, Stil, oder auf englisch Style

Tya und auf solche Antworten wie von dir scheiße kann ich getrost verzichten da diese mir nicht helfen.

Hast du zufällig ein kleines Beispiel Matze?

if()
{  //Klammernpaar 1 wird in Spalte 0 geöffnet

  //nach einer geschweiften Klammer werden 2 Stellen eingerückt
  if()
  {    //Klammernpaar 2 wird in Spalte 2 geöffnet  
    //...
  }    //Klammernpaar 2 wird in Spalte 2 geschlossen

}  //Klammernpaar 1 wird in Spalte 0 geschlossen

Du kannst natürlich auch eine Tabweite von 3 oder 4 benutzen. Wichtig ist die konsequente Anwendung von solchen Regeln.

mehr als 3 Ebenen stinken!

void function()
{
    if( /* erste */ )
    {
        while( /* zweite */ )
        {
            if( /* dritte - äußerstes maximum! */ )
            {
            }
        }
    }
}

das hebt sich natürlich ein bisschen auf, da man gewöhnlich in namespaces und klassen noch ein wenig weiter einrückt, aber mehr sollten es nicht sein. kleiner tipp, wie man sowas bewerkstelligen kann:

anstatt

void myoutput(mytype* ptr)
{
    if(ptr)
    {
        if(ptr->whatever())
        {
            if(!ptr->is_set())
            {
                // do stuff
            }
        }
    }
}

lieber

void myoutput(mytype* ptr)
{
    if(!ptr)
        return; // vorzeitig raus

    if(ptr->whatever() && !ptr->is_set())
    {
        // do stuff
    }
}

von der 3. auf die 1. einrückungsebene runter

Danke

Super Xantus wusst gar ned das es sowas gibt hmm gefällt mir werd ich gleich mal ausprobieren und es wo einbauen!

Was für return in Funktionen gilt, kannst du auch mit break in Schleifen anwenden, um diese zu verlassen. continue führt in Schleifen dazu, dass der nächste Schleifendurchgang beginnt.

Rein syntaktisch isses egal wo die Klammern sind, wir sind hier nicht bei Python :P.

Stimmt, mit Python brauchst Du nämlich die ganzen geschwungenen Klammern nicht.

Scorcher24 schrieb:

Rein syntaktisch isses egal wo die Klammern sind, wir sind hier nicht bei Python :P.

Stimmt, mit Python brauchst Du nämlich die ganzen geschwungenen Klammern nicht.

Das stimmt, aber da müssen die Einrückungen stimmen
rya.

void myoutput(mytype* ptr)
{
    if(!ptr)
        return; // vorzeitig raus

    if(ptr->whatever() && !ptr->is_set())
    {
        // do stuff
    }
}

Das ist aber auch nicht immer sinnvoll. Denn so muss man bei jedem return alles freigeben was per new erstellt wurde.

Das ist aber auch nicht immer sinnvoll. Denn so muss man bei jedem return alles freigeben was per new erstellt wurde.

Das Problem hast Du immer, denn Du vergisst die "versteckten Returns" (throw in dieser Funktion oder noch schlimmer throw in aufgerufener Funktion). Deshalb schützt man auch alles per new erstellte immer mit Guards. RAII lässt grüßen

Fellhuhn schrieb:

Das ist aber auch nicht immer sinnvoll. Denn so muss man bei jedem return alles freigeben was per new erstellt wurde.

Das Problem hast Du immer, denn Du vergisst die "versteckten Returns" (throw in dieser Funktion oder noch schlimmer throw in aufgerufener Funktion). Deshalb schützt man auch alles per new erstellte immer mit Guards. RAII lässt grüßen

In den meisten Fällen viel zu viel Aufwand. Zumindest in meinem aktuellen Projekt das schon mehrere Tausend Klassen etc. hat nicht vertretbar. Mit Exceptions wird da aber auch eh nicht gearbeitet.