Programmierstil?

EXDW

Für C# kann bei bei der Formatierung jeden Pups einstellen

Für Zeile ausschneiden nehm ich immer SHIFT+ENTF - komm ich schneller ran, da die rechte Hand in dieser Situation eh auf den Pfeiltasten ist, ist der Zeigefinger schnell auf ENTF ein stück hoch gerutscht als wenn ich noch das l suchen muss

PS. mit ALT+Pfeiltasten kann man die Aktuelle Zeile mit der darunter oder darüber tauschen (Cursor wandert mit) so kann man auch schnell Zeilen verschieben.
Kann aber sein das dass mit den Produtivity Power Tools rein gekommen ist (Mit diesem Add-on ist das Arbeiten ein Traum, so viele geile Features :))

volkard

David W schrieb:

PS. mit ALT+Pfeiltasten kann man die Aktuelle Zeile mit der darunter oder darüber tauschen (Cursor wandert mit) so kann man auch schnell Zeilen verschieben.

Supi Idee! Das will ich auch haben.

Michael E.

GPC schrieb:

volkard schrieb:

Eisflamme schrieb:

Das macht ihn ja trotzdem nicht besser. Oder war deine Aussage, dass dieser Stil automatisch von der IDE auf dauer ausgerottet wird?

Nö. Wenn ich mich recht erinnere, läßt MSVC beide Stile zu. Es rückt nur ein, schubst aber keine Klammern in eigene Zeilen oder klebt sie an Vorgängerzeilen.

Man kann es so einstellen, dass es die Klammern in eigene Zeilen schubst, an Vorgängerzeilen klebt oder die Klammern in Ruhe lässt.

Dumme Frage: Wo (VS 2008)?

EXDW

volkard schrieb:

David W schrieb:

PS. mit ALT+Pfeiltasten kann man die Aktuelle Zeile mit der darunter oder darüber tauschen (Cursor wandert mit) so kann man auch schnell Zeilen verschieben.

Supi Idee! Das will ich auch haben.

http://visualstudiogallery.msdn.microsoft.com/d0d33361-18e2-46c0-8ff2-4adea1e34fef/
"Move Line Up/Down Commands"

abc.w

GPC schrieb:

... Übrigens gibt es sowohl in vi als auch in emacs (wenn wir von Linux reden) effizientere Tastenkombos, um auszuschneiden, sich zu bewegen und wieder einzufügen...

Ja, aber vielleicht sind sie gleichzeitig auch deren Nachteil - man denkt nicht mehr über den Code nach - merke ich bei mir ab und zu. Die Kommandos lassen sich automatisieren und so habe ich plötzlich aus einer Header-Datei 200 Definitionen kopiert und daraus, ohne großartig nachzudenken, ein switch mit 200 cases halbautomatisch generiert, natürlich alle nach meinem Lieblingsstil. D.h. aus diesem Code:

#define SOME_DEFINITION_0    0x1234u
#define SOME_DEFINITION_1    0xAAAAu
#define SOME_DEFINITION_2    0xDEAEu
...
#define SOME_DEFINITION_200  0xDEADu

hat man sich bequem so was hier generiert:

switch (value)
    {
        case SOME_DEIFINITION_0:
            {
                break;
            }
            /* ab hier etwa 200 weitere cases halb automatisch mit meinem Lieblingseditor generiert */
        default:
            {
                break;
            }   
    }

Wer will so was noch freiwillig warten...

GPC

Michael E. schrieb:

GPC schrieb:

volkard schrieb:

Eisflamme schrieb:

Das macht ihn ja trotzdem nicht besser. Oder war deine Aussage, dass dieser Stil automatisch von der IDE auf dauer ausgerottet wird?

Nö. Wenn ich mich recht erinnere, läßt MSVC beide Stile zu. Es rückt nur ein, schubst aber keine Klammern in eigene Zeilen oder klebt sie an Vorgängerzeilen.

Man kann es so einstellen, dass es die Klammern in eigene Zeilen schubst, an Vorgängerzeilen klebt oder die Klammern in Ruhe lässt.

Dumme Frage: Wo (VS 2008)?

Sorry mein Freund, leider nur für C#

Edit: Die Productivity-Tools sollte aber wirklich jeder haben, die sind super

abc.w

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

EXDW

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

*john 0

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--; 
        }

*john 0

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.

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