Programmierstil?



  • Sehe ich das richtig, diese Productivity Tools sind auch von Microsoft? Warum baut man sie denn nicht direkt in MS Visual Studio ein 😕



  • Weiß ich auch nicht genau, ich kann mir aber vorstellen das damit auch experimentiert wird was die Customer wollen, sodass features davon in den nächsten release einfließt.
    Genauso wurdes (wirds?) auch mit dem WPFToolkit gemacht.

    Die vorteile es über ein Plugin zu lösen:
    - Man kann leicher Patchen,
    - Es muss nicht bei jeden Stabil sein, es kann auch deinstalliert werden als fallback



  • Da ich nicht nur in C artigen Sprachen programmiere, ist die öffnenden Klammern in einer separaten Zeile einfach nur Bloat, die einzige Ausnahme ist es, wenn Funktionsdefinitionen umgebrochen werden müssen.

    Glühbirne schrieb:

    Mir ist Lesbarkeit am wichtigsten, danach der Platz. In der Praxis sieht das so aus:

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

    Die Einrückung ist als Markierung der Schachtelungstiefe ausreichend. Python macht es vor, daß das vollkommen ausreichend ist.

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


  • dir ist "lesbarkeit wichtig" aber du schreibst sowas:

    if(a--) 
                break; 
            else 
            { 
                a++; 
                b--; 
            }
    

    😕 😕 😕 😕



  • BierzeltOmi schrieb:

    dir ist "lesbarkeit wichtig" aber du schreibst sowas:

    Richtig zitieren!



  • ~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.



  • 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:

    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.



  • 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.



  • _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?



  • 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.



  • 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.
    


  • 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



  • 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



  • _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");
    


  • -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);
    

Anmelden zum Antworten