Ist mein Styl so schrecklich?

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

Fellhuhn

LordJaxom schrieb:

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.

LordJaxom

Und in Projekten mit tausenden Klassen, die mit Exceptions arbeiten?

BTW, was ist an einem shared_ptr< xyz > x( new xyz ) so viel weniger vertretbar als an xyz* x = new xyz; ..... delete x; ?

Fellhuhn

Wie lange ist das schon im Standard? Weil einige unserer (gnu) Compiler haben hier schon mit at() von std::vector Probleme.

asc

Fellhuhn schrieb:

Wie lange ist das schon im Standard? Weil einige unserer (gnu) Compiler haben hier schon mit at() von std::vector Probleme.

Naja, einige Firmen haben ja auch noch mit C++98 Probleme... da kann man verstehen warum einige Compiler noch keine TR1 unterstützung haben, oder sich Einige alternativ gegen die Boost-Bibliotheken stemmen (die ja sowohl eine TR1 Umsetzung mitbringt als auch die Smartpointer innerhalb des boost-Namensraumes)...

cu André

Fellhuhn

Wenn der Code über 12 Jahre alt ist, sind es die Kunden meist auch (also die Systeme die die haben, nicht die Kunden selbst :D) und dann wollen die ständig Neuentwicklungen aber keine neuen Rechner... Naja... Wirtschaft halt.