Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

[C++11] Suche Feedback zu meinem CodingStyle

  • 1
  • 2

Werbeanzeige

xardias

Community-Fossil

Beiträge: 2 731

Wohnort: Santa Clara, CA

Beruf: Software Engineer

  • Private Nachricht senden

11

29.01.2015, 04:35

Der Stil sieht denke ich sehr solide aus.

Bei der groesse des Projekts momentan macht es noch nicht viel aus, aber generell wuerde ich empfehlen ein paar Unit Tests hinzu zufuegen. Zumindestens fuer die Komponenten die sich ohne zu viel Aufwand testen lassen.


Was ich aus dem Google Style Guide mittlerweile sehr mag ist indentation mit spaces. Wenn man statt fixer indentierung von langen Zeilen den indent an Klammern oder den Kontext anpasst werden umgebrochene Zeilen oft ne ganze ecke uebersichtlicher. z.B.

C-/C++-Quelltext

 
1
2

test = Call(parama, paramb,
            paramd) # relativ zur klammer


statt

C-/C++-Quelltext

 
1
2

test = Call(parama, paramb,
        paramd) # 8 space fixed


Leider kommt das mit dem Google Style guide sehr haeufig vor, da das 80 Zeichen Zeilenmaximum strikt eingehalten wird :(

Aber generell was indentierung angeht bleibt das ziemlich Geschmackssache. Ich mochte Tabs lange Zeit wesentlich lieber da es flexibler ist und jeder Entwickler die groesse in seinem Editor anpassen kann.

Hello_Kitty!

unregistriert

12

29.01.2015, 06:45

80 Zeichen lange Zeilen sind völlig überholt und die Begründung im Google-Styleguide dazu ist auch sehr schwach. Mit 100 (Zielmarke) / 110 (harte Grenze) Zeichen langen Zeilen passen auf einen normalen 1920x1200 Monitor auch noch problemlos zwei Dateien nebeneinander, sogar mit vierstelligen Zeilennummern und beidseitigen Scrollbars.

Eine Einrückung nur mit Spaces hat den Nachteil, dass die logische Tiefe verloren geht und sich die visuelle Tabbreite nicht mehr zuverlässig verändern lässt.

C-/C++-Quelltext

 
1
2
3
4
5
6

// Mapping von 4 Leerzeichen auf visuelle Tabbreite 4:
if(true)
{
    test = Call(parama, paramb,
                paramd) # relativ zur klammer
}

C-/C++-Quelltext

 
1
2
3
4
5
6

// Mapping von 4 Leerzeichen auf visuelle Tabbreite 8:
if(true)
{
        test = Call(parama, paramb,
                                        paramd) # relativ zur klammer
}


Wenn man mit Tabs nur auf die logische Ebene einrückt und Leerzeichen zur weiteren Formatierung verwendet, wird dieses Problem vermieden (Punkte sind Leerzeichen):

C-/C++-Quelltext

 
1
2
3
4
5
6

// Tabbreite 4
if(true)
{
    test = Call(parama, paramb,
    ............paramd) # relativ zur klammer
}

C-/C++-Quelltext

 
1
2
3
4
5
6

// Tabbreite 8
if(true)
{
        test = Call(parama, paramb,
        ............paramd) # relativ zur klammer
}



@Glocke: Deine Klammernsetzung finde ich ungewöhnlich, hat nicht sogar K&R die öffnende Klammer einer Funktion in einer neuen Zeile?

Glocke

Treue Seele

  • »Glocke« ist der Autor dieses Themas

Beiträge: 341

  • Private Nachricht senden

13

29.01.2015, 08:22

Zitat von »xardias«

Bei der groesse des Projekts momentan macht es noch nicht viel aus, aber generell wuerde ich empfehlen ein paar Unit Tests hinzu zufuegen. Zumindestens fuer die Komponenten die sich ohne zu viel Aufwand testen lassen.

Ein paar Unit-Tests sind ja dabei, aber es könnten mehr sein, da gebe ich dir Recht :)

Zitat von »xardias«

Aber generell was indentierung angeht bleibt das ziemlich Geschmackssache. Ich mochte Tabs lange Zeit wesentlich lieber da es flexibler ist und jeder Entwickler die groesse in seinem Editor anpassen kann.

Ich war lange Zeit ein Freund von Spaces und bin nun zu Tabs gewechselt :D

Zitat von »Hello_Kitty!«

80 Zeichen lange Zeilen sind völlig überholt und die Begründung im Google-Styleguide dazu ist auch sehr schwach. Mit 100 (Zielmarke) / 110 (harte Grenze) Zeichen langen Zeilen passen auf einen normalen 1920x1200 Monitor auch noch problemlos zwei Dateien nebeneinander, sogar mit vierstelligen Zeilennummern und beidseitigen Scrollbars.

Ich sehe das ganz anders: Die 80 sind für mich persönlich genau richtig. Meistens kann man es vermeiden, dass der Code so "tief" verschachtelt wird, so dass i.d.R. nur Signaturen die Zeilenlänge überschreiten (was mir auch das ein oder andere mal glaube passiert ist).
Nebeneffekt er 80 Zeichen für mich: Ich arbeite prinzipiell an meinem Netbook (Zug, Uni & Zuhause, ich bin kein Freund davon ständig das Gerät zu wechseln ^^) und da sind die 80 Zeichen passgenau, wenn man an der Seite noch eine Liste von Symbolen oder Files offen hat :)
Bei einer Auflösung von 1920x1200 erscheint das sicherlich stark in die Länge gezogen aber ich persönlich habe nichtmal so einen Monitor :D Kp ob das inzwischen bei jedem Standard ist ... *wie ein Dinosaurier fühl*

Zitat von »Hello_Kitty!«

Wenn man mit Tabs nur auf die logische Ebene einrückt und Leerzeichen zur weiteren Formatierung verwendet, wird dieses Problem vermieden (Punkte sind Leerzeichen):

Ein Vermischen von Tabs und Spaces zur Einrückung habe ich mir abgewöhnt - auch weil ich ansonsten viel mit Python arbeite. Imho ist es generell kein guter Stil beides zu vermischen :S

Zitat von »Hello_Kitty!«

Deine Klammernsetzung finde ich ungewöhnlich, hat nicht sogar K&R die öffnende Klammer einer Funktion in einer neuen Zeile?

Wenn K&R mit einer öffnenden Klammer aus dem Fenster springen, will ich nicht hinterher springen müssen :D
Spaß bei Seite ^^ Ich weiß nicht mehr seit wann ich das mache, aber es ist schon sehr lange her xD Im Endeffekt hat das ganze für mich genau einen Grund, nämlich das Fehlen des Grundes, warum ich für { eine extra Zeile brauche xD Wenn ich eine Funktion habe, sieht man ja eigentlich "aha, eine Signatur, danach gehts eingerückt weiter", so dass die öffnende Klammer nur noch eine syntaktische Notwendigkeit ist.

Und wo wir gerade bei Klammern sind: Prinzipiell klammere ich auch einzeilige Branches (z.B. nach if)... häufig will man dann doch noch eine zweite Zeile (und sei es um etwas in eine Logfile zu schreiben) hinzufügen und fügt dann die Klammern eh hinzu :)

Was den Google Coding-Style angeht .. wie ihr sicher gesehen habt, habe ich einige Sachen daraus übernommen - andere aber nicht. Beispielsweise schreibe ich Variablen und Parameter immer mit Underscores, Typen und Funktionen/Methoden immer im CamelCase. Ich persönlich komme orientierungstechnisch mit einem reinen CamelCase oder einem Underscore-Only Code irgendwie nicht klar .. da "verschwimmt" alles zu einer Masse von CamelCases oder Underscores xD

LG Glocke

xardias

Community-Fossil

Beiträge: 2 731

Wohnort: Santa Clara, CA

Beruf: Software Engineer

  • Private Nachricht senden

14

29.01.2015, 22:27

Zitat von »Hello_Kitty!«

80 Zeichen lange Zeilen sind völlig überholt und die Begründung im Google-Styleguide dazu ist auch sehr schwach. Mit 100 (Zielmarke) / 110 (harte Grenze) Zeichen langen Zeilen passen auf einen normalen 1920x1200 Monitor auch noch problemlos zwei Dateien nebeneinander, sogar mit vierstelligen Zeilennummern und beidseitigen Scrollbars.

Mit 80 Zeichen langen Zeilen kriege ich 3 Dateien aufm Laptop nebeneinander :P

Ernsthafte Antwort... Ich bin auch nicht sehr gluecklich darueber. Je nach Team bei Google kommt es jedoch durchaus haeufig vor, dass man mal aufm Linux terminal mit code arbeiten muss. Da ist das dann ganz praktisch. Aber im Endeffekt haette ich auch lieber laengere und uebersichtlichere Zeilen.

Werbeanzeige

  • 1
  • 2

Ähnliche Themen