Ist mein Styl so schrecklich?

Nein, es ist überhaupt nicht übersichtlich, was hast du von einer Tabstopgröße von 8?
Es reichen schon 2 um sehr gut erkennen zu können, dass hier eingerückt wurde.

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.

_matze

Du hast scheinbar nicht verstanden, wie das Einrücken funktioniert! Wenn du einen Block (z.B. if) aufmachst, dann musst du ihn auf der gleichen vertikalen Ebene wieder schließen, so:

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?

Berufspenner

Rein inhaltlich ist es ganz normal, wenn dein Code einfach noch nicht "schön" ist. Du bist aber Anfänger und da ist es ganz normal. Rein von der Optik deiner Textstruckturierung ist aber schon zu sagen, dass er, zumindest für meine Vorstellungen, recht unschön ist. Eine Tabweite von vier Leerzeichen ist viel angenehmer zu lesen. Einen Funktions- oder Schleifenblock z.B. öffne ich immer mit eine geschweiften Klammer, die in einer eigenen Zeile steht. Schließe ich den Block, kommt die geschweifte klammer ebenfalls in einer eigenen Zeile direkt unter die erste. Damit behält man auch besser die Übersicht und man vergisst nicht so leicht mal einen Block zu schließen.

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

_matze

Styler2008 schrieb:

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.

Hast du zufällig ein kleines Beispiel Matze?

Du benutzt doch sicher einen Editor der C++ versteht, also dir Schlüsselwörter farbig markiert usw., richtig?
Schau mal ob der unter Bearbeiten/Edit eine Option hat um markierten Code zu formatieren, bzw. die gesamte Datei zu formatieren und benutze diese einmal.
Dann solltest du sofort sehen was gut eingerückter Code ist.

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

scheiße is der style kacke du bist wohl kein styler haaaaaaaaaaaaaaaaaaaaaahaaaa

Nexus

Ich schliesse mich den Vorschlägen in den anderen Antworten an, zusätzlich habe ich noch einige Details:

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

Danke Tipp

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

Danke NEXUS echt klasse

_matze

Styler2008 schrieb:

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.

Xantus

Grundsätzlich kannste dir merken:

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

Also die Einrückung ist schon etwas groß, da schliess ich mich an :).
Aber ich würds nicht so schwer nehmen, hehe. Das kommt alles mit der Zeit. Rein syntaktisch isses egal wo die Klammern sind, wir sind hier nicht bei Python :P.
Allerdings merkst du es mit der Zeit selbst wie du Deinen Code am besten nach 3 Monaten wieder verstehst. Wenn andere Deinen Code lesen MÜSSEN ist es wieder was anderes.
Kommt Zeit, kommt Wissen, kommt Code-Style..
Mach Dir wie gesagt keinen Kopf
rya.

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

Danke

Nexus

Styler2008 schrieb:

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.

nman

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.

nman schrieb:

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.

Fellhuhn

Xantus schrieb:

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.

LordJaxom

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