Programmierstil?

~john schrieb:

BierzeltOmi schrieb:

dir ist "lesbarkeit wichtig" aber du schreibst sowas:

Richtig zitieren!

Ist hier jemand ein bisschen Egozentrisch? Ich hab doch gar nicht auf dich geantwortet...

Ach, ~john hat Probleme mit dem Textverstandnis.

*john 0

BierzeltOmi schrieb:

Ist hier jemand ein bisschen Egozentrisch? Ich hab doch gar nicht auf dich geantwortet...

Woher weiß man das? Ohne Quotes ist die Sache nicht eindeutig, wenn Deine Antwort direkt unter meiner steht.

nach vielen Jahren und dem Ausprobieren verschiedener Stile - insbesondere dem Lesen von sehr viel fremdem Code - hat sich für mich als lesbarste Variante heraus gestellt:

Einrücken mit Allman-Stil ( http://en.wikipedia.org/wiki/Indent_style#Allman_style_.28bsd_in_Emacs.29 )
Einrücktiefe 4, Tabs durch Spaces ersetzt
Benennen mit lowerCamelCase für Variablen, Klassenmember, etc.
Benennen mit UpperCamelCase für Klassen, Typen, etc.

Interessanterweise nutzen viele meiner Bekannten denselben Stil (obwohl ich nicht mit ihnen zusammen gearbeitet habe) über die verschiedenen C-Syntax abgeleiteten Sprachen (C, C++, Java, C#) hinweg.

_matze

gastgast schrieb:

[*] Einrücktiefe 4, Tabs durch Spaces ersetzt

Warum durch Spaces ersetzt? Wenn ich deinen Code in meinem Editor lesen will, möchte ich doch eigentlich meine Einrücktiefe haben, weil ich mich seit Jahren daran gewöhnt habe, und nicht die von dir fest vorgegebene.

P.S.: Bitte nicht gleich steinigen, wenn das Thema schon behandelt wurde. Habe nicht den ganzen Thread gelesen.

*rant*

_matze schrieb:

gastgast schrieb:

[*] Einrücktiefe 4, Tabs durch Spaces ersetzt

Warum durch Spaces ersetzt? Wenn ich deinen Code in meinem Editor lesen will, möchte ich doch eigentlich meine Einrücktiefe haben, weil ich mich seit Jahren daran gewöhnt habe, und nicht die von dir fest vorgegebene.

Ich lasse Tabs ebenfalls durch Spaces ersetzen mit Einrücktiefe 4. Der Vorteil ist, dass der Code dann überall gleich aussieht. Wenn man lange Bezeichner hat, ist es sinnlos mit Tabs einrücken zu wollen, da diese je nach Einstellung anders reagieren können.

/rant/ schrieb:

Der Vorteil ist, dass der Code dann überall gleich aussieht.

Ist das nicht genau der Nachteil? Schließlich will ich vielleicht eine Tiefe von 8 sehen und mein Kollege von 2. Mit Tabs möglich, mit Spaces ärgern wir uns beide über die 4er-Einrückung.

/rant/ schrieb:

Wenn man lange Bezeichner hat, ist es sinnlos mit Tabs einrücken zu wollen, da diese je nach Einstellung anders reagieren können.

Das verstehe ich nicht, was meinst du?

Eisflamme

Na ja, vll so was:

void          bla();
const string& blub();

Einrücken mit Tabs ist schade, wenn der andere es anders eingestellt hat.

Klingt so, als wenn man hier mit Leerzeichen und bei den Verschachtelungsebenen mit Tab einrücken sollte.

Oh, man muss natürlich die einzige Grundregel beachten: Einrücken mit Tabs, Ausrichten mit Spaces.

Soll heißen, in deinem Beispiel muss man natürlich Spaces nehmen. Allgemein scheinen viele ein Verständnisproblem zu haben mit dem Unterschied Einrückung<->Ausrichtung, ist meiner Meinung nach auch der Hauptgrund, warum sich Tabs als Einrückung nicht durchsetzen können/konnten.

volkard

Eisflamme schrieb:

Na ja, vll so was:

void          bla();
const string& blub();

Zum Glück          macht                  man sowas nicht. 
Es                 wäre                   völlig              verrückt, 
ähnliche Bausteine senkrecht auszurichten. 
Leider             muß                    ich sowas recht oft sehen. 
Mich               stört                  es jedenfalls im Lesefluß ungemein.

EOutOfResources

volkard schrieb:

Zum Glück macht man sowas nicht.
Es wäre völlig verrückt,
ähnliche Bausteine senkrecht auszurichten.
Leider muß ich sowas recht oft sehen.
Mich stört es jedenfalls im Lesefluß ungemein.

+1

_matze

EOutOfResources schrieb:

volkard schrieb:

Zum Glück macht man sowas nicht.
Es wäre völlig verrückt,
ähnliche Bausteine senkrecht auszurichten.
Leider muß ich sowas recht oft sehen.
Mich stört es jedenfalls im Lesefluß ungemein.

+1

+2

Jockelx

_matze schrieb:

EOutOfResources schrieb:

volkard schrieb:

Zum Glück macht man sowas nicht.
Es wäre völlig verrückt,
ähnliche Bausteine senkrecht auszurichten.
Leider muß ich sowas recht oft sehen.
Mich stört es jedenfalls im Lesefluß ungemein.

+1

+2

-1
Finde das manchmal gut lesbar.

bla = getValueOf("bla");
blubbe = getValueOf("bla");
blubbla = getValueOf("blubbla");

// Fehler fällt sofort auf:
bla     = getValueOf("bla");
blubbe  = getValueOf("bla");
blubbla = getValueOf("blubbla");

Eisflamme

-1 und wir sind bei 0...

Ich mache das überall in meinem Coding. Auch in obigem Beispiel. Wieso? Wenn der Leser eine Übersicht über meine Methoden erhalten möchte, soll er sich die Namen anschauen. Bei längeren Rückgabetypen fällt es manchmal schwer die Namen zu finden. Wenn ich das "senkrecht anordne", kann man die Namen schnell überschlagen. Möchte man zu einer Funktion den Rückgabetypen finden, ist das kein Problem. Man findet schnell den richtigen Namen und kann von da aus dorthin navigieren, wo man möchte. Selbiges gilt für Attributnamen.

Hier ein Beispiel:

MeshHolderVector&	GetMeshHolders()	{return meshHolders_;}
		Mesh&				GetMesh()			{return aggregatedMesh_;}
		MaterialMap&		 GetMaterialMap()	{return materialMap_;}
		TextureMap&		  GetTextureMap()		{return textureMap_;}
		AnimationMap&		GetAnimationMap()	{return animations_;}
		ModelNodePtr	     GetRootNode()		{return rootNode_;}
		const ModelNodePtr   GetRootNode() const	{return rootNode_;}
		void				 SetRootNode(const ModelNodePtr node);
		void				 CacheNodes();

(Ist ein älteres Codebeispiel, ich habe für die ganzen bis dato benötigten Referenz-Getter jetzt eine bessere Lösung gefunden).

Hier sieht man die Namen auf einen Blick. Jetzt so, als würde man Code wie deutsche Sätze schreiben:

MeshHolderVector& GetMeshHolders() {return meshHolders_;}
		Mesh& GetMesh() {return aggregatedMesh_;}
		MaterialMap& GetMaterialMap() {return materialMap_;}
		TextureMap& GetTextureMap() {return textureMap_;}
		AnimationMap& GetAnimationMap() {return animations_;}
		ModelNodePtr GetRootNode() {return rootNode_;}
		const ModelNodePtr GetRootNode() const {return rootNode_;}
		void SetRootNode(const ModelNodePtr node);
		void CacheNodes();

Huch.

-1 und das Spiel ist gekehrt

Sieht schön aus, ist übersichtlich, Fehler werden schnell erkannt und ein guter Editor unterstützt einen noch dazu.

Für das Beispiel von Jockelx tippt man

bla     = "bla");
blubbe  = "bla");
blubbla = "blubbla");
M-b C-<SPC> C-p C-p C-x r t getValueOf("<RET>

(letzeres ist ein Editor-Command in Emacs. M=Alt, C=Control)

Dass das Problem von Eisflamme auch in gutem Code auftritt zeigt folgender Code aus GTK+ (ist halt C):

gboolean   gtk_widget_activate               (GtkWidget        *widget);
gboolean   gtk_widget_set_scroll_adjustments (GtkWidget        *widget,
                                              GtkAdjustment    *hadjustment,
                                              GtkAdjustment    *vadjustment);

void	   gtk_widget_reparent            (GtkWidget           *widget,
                                           GtkWidget           *new_parent);
gboolean   gtk_widget_intersect           (GtkWidget           *widget,
                                           const GdkRectangle  *area,
                                           GdkRectangle        *intersection);
GdkRegion *gtk_widget_region_intersect    (GtkWidget           *widget,
                                           const GdkRegion     *region);

void	gtk_widget_freeze_child_notify    (GtkWidget           *widget);
void	gtk_widget_child_notify           (GtkWidget           *widget,
                                           const gchar         *child_property);
void	gtk_widget_thaw_child_notify	  (GtkWidget	       *widget);

*Rewind*

Wie du das machst ist am Ende dir überlassen. Es soll nur möglichst übersichtlich und konsistent sein. Ich bevorzuge diese Variante (mit Leerzeichen und line breaks):

int main()
{
    int a=3, b=5;
    for (int i = 0; i < b; i++)
    {
        if (a--)
            break;
        else
        {
            a++;
            b--;
        }
    }
    return 0;
}

Da wäre es ja glatt schön, wenn der Funktionsname zuerst käme:

GetMeshHolders: () -> MeshHolderVector&;
GetMesh: () -> Mesh&;
GetMaterialMap: (int Par1, string Par2) -> MaterialMap&;

Oder so.

P.S.: +1

int main()
{
    int a=3, b=5;

    for (int i=0; i<b; i++) {
        if (a--) {
            break;
        } else {
            a++;
            b--;
        }
    }
}

[/quote]

Eisflamme

asdgg, das zählt nicht.

zwutz

just another c hacker schrieb:

Sieht schön aus, ist übersichtlich, Fehler werden schnell erkannt und ein guter Editor unterstützt einen noch dazu.

ein guter Editor zeigt dir alle Funktionen und Methoden in einem extra Fenster an

Ich hasse diese ewigen Anpassungen am Codeaussehen, wenn eine Methode hinzugefügt wurde. Oder sich anderweitig die Länge geändert hat.
Der Code sollte so geschrieben werden, dass Änderungen keinen Einfluss auf die Struktur des restlichen Codes haben sollten. Ich seh in den diffs immer so Späße. Plötzlich kommt 90% der Datei als modified daher, nur weil jemand überall ein Leerzeichen hinzufügen musste, damit es wieder glatt aussieht.