Schreibweise von Membervariablen



  • Der Nutzen und Sinngehalt von Typenpräfixen relativiert sich sofort, wenn man (wie man es sowieso immer tun sollte) seine Variablen sinnvoll und sprechend benennt.

    Klar, hier hab ich Probleme:

    c = a + b;

    Die werden aber hierdurch:

    ic = ia + ib;

    nur bedingt gelöst (ich weiß nun, dass das alles int sind, aber hilft mir das jetzt wirklich weiter?)

    Hier, hab ich keine Probleme, auch ohne "i" davor nicht:

    width = borderWidth + clientWidth;

    Dass man, sollte man sich tatsächlich mal nicht sicher sein (auch nicht aufgrund des Variablennamens) um welchen Typ es sich handelt, nur kurz mit dem Mauszeiger auf diese Variable geht, muss ich nicht mehr erwähnen, oder? Aber dieser Fall tritt (bei mir zumindest) äußert selten bis nie ein.

    Naja, das Thema wurde hier denke ich zur Genüge durchgekaut und eigentlich dachte ich, es hätte sich rumgesprochen, dass der Typ-Präfix heutzutage ein "no-go" ist - wie man sich täuschen kann. 😉

    Zum Gesetz der Geschlossenheit oder was auch immer: das Übertragen von irgendwelchen Designgesetzen auf die Formatierung von Quellcode halte ich dann doch für etwas zu gewagt... oder vielleicht sollte man auch noch etwaige Gesetze aus der Farbenlehre berücksichtigen?

    Wie gesagt: wurde hier alles schon oft durchgekaut (von weitaus kompetenteren Leuten wie mir), einfach mal die Suche bemühen. Mir ist es wirklich komplett schnuppe, wie ihr euren Code formatiert, solange ich den niemals bearbeiten muss.



  • F98 schrieb:

    [...]

    public int Blah1(int a, int b)
    {
       return a + b;
    }
    
    public int Blah2(int a, int b)
    {
       return a * b;
    }
    
    public int Blah3(int a, int b)
    {
       return a / b;
    }
    
    public int Blah4(int a, int b)
    {
       return a - b;
    }
    
    public int Blah5(int a, int b)
    {
       return Blah3(Blah1(a, b) - Blah2(a, b), Blah4(a, b));
    }
    

    Ist zwar schön alles kurz gehalten, irgendwie bekommt man aber doch einen Anfall dabei.

    Sorry, hatte noch vergessen zu erwähnen, dass die Lösung für das Problem "Superlangeberechnungdienurin10zeilenpasst" nicht unbedingt im Aufsplitten auf separate Funktionen bestehen muss:

    public int Blah5( int a, int b ) {
    
      int blah1 = a + b;
      int blah2 = a * b;
      int blah3 = a - b;
    
      return ( blah1 - blah2 ) / blah3;
    }
    

    Aber ohne sprechende Variablennamen ist das alles "Schrunz". Mit "i" davor wird's "Schrunz-mit-i-davor". Wenn jetzt "a + b", "a * b" und "a - b" noch einen Sinn haben und man statt blah1-3 die Variablen sinnvoll benennt, dann - wow - dann könnte man sogar evtl. auf einen Blick den Sinn der Berechnung erkennen. Und ein "i" davor würde wobei helfen? Genau. 😉



  • SolidOffline schrieb:

    Zum Gesetz der Geschlossenheit oder was auch immer: das Übertragen von irgendwelchen Designgesetzen auf die Formatierung von Quellcode halte ich dann doch für etwas zu gewagt... oder vielleicht sollte man auch noch etwaige Gesetze aus der Farbenlehre berücksichtigen?

    Gehört zwar nicht zur Farbenlehre, aber ich denke sowas wie Syntaxhighlighting spielt schon eine wichtige Rolle beim Programmieren.



  • Hallo

    @F98: Ich meinte eher, was du machst, wenn du Member hast, die Instanzen eigener Klassen sind. Was verwendest du dann für einen Präfix? Des weiteren sehe ich das Problem, das Präfixe im Grunde Kommentare sind und wenn sich der Datentyp ändert es schnell und leicht passieren kann, dass die Kommentierung nicht mehr mit der Realität übereinstimmt.

    chrische



  • Ist schon lustig, wie immer Leute mit dem Argument kommen, dass man den Typ einer Variable doch per Tooltip betrachten kann. Dabei sagte ich ja gerade, dass das manchmal einfach umständlich ist und weitere Aktionen (Maus) verlangt. Nervig! Außerdem ist das abhängig von der IDE, in einem anderen Editor (auch, wenns eigentlich selten vorkommt) kann man es dann total vergessen und muss immer zur Deklaration springen.

    Na ja, JEDEM DAS SEINE!



  • int sTest;

    Und schon ist der Typ klar 😉



  • Knuddlbaer schrieb:

    int sTest;

    Und schon ist der Typ klar 😉

    Genau 😉

    oder

    SehrToedlicherRabiaterIntelligenterNervigerGegner stringTest;
    


  • chrische5 schrieb:

    Hallo

    @F98: Ich meinte eher, was du machst, wenn du Member hast, die Instanzen eigener Klassen sind. Was verwendest du dann für einen Präfix? Des weiteren sehe ich das Problem, das Präfixe im Grunde Kommentare sind und wenn sich der Datentyp ändert es schnell und leicht passieren kann, dass die Kommentierung nicht mehr mit der Realität übereinstimmt.

    chrische

    Allgemein mach ich nichts außer "_" für privates + Typpräfix für Basistypen.

    Typpräfixe für Basistypen:

    int - i
    short - si
    string - s
    byte - by
    unsigned int ui
    bool b

    usw.

    Bei Instanzen eigener Klassen lasse ich den Typpräfix weg, da sich kein eindeutiger, kurzer und sinnvoller Präfix finden lässt. Ich bin daher bestrebt nur "kleine" Klassen zu schrieben, die Basistypen + 1-2 eigene Typen beinhalten. Meistens sind die eh in Listen.



  • F98 schrieb:

    short - si

    Und bereits hier hätte ich meine ernsten Probleme, obwohl ich zeitweise auch UN betrieben habe. UN erzwingt das lernen einer zweiten Sprache (den eben das ist UN).



  • int sTest;
    
    ...
    
    SehrToedlicherRabiaterIntelligenterNervigerGegner stringTest;
    

    Wer seine Variablen so benennt, dem ist wahrlich nicht mehr zu helfen. Mit der selben Argumentation kann man auch andere einfache Regularien ad absurdum führen. Das ist aber eher kontraproduktiv.



  • asc schrieb:

    F98 schrieb:

    short - si

    Und bereits hier hätte ich meine ernsten Probleme, obwohl ich zeitweise auch UN betrieben habe. UN erzwingt das lernen einer zweiten Sprache (den eben das ist UN).

    Es gibt wenige klitzekleine Merkmale - 10 Buchstaben, die ich mir merken sollte.
    So schwer ist es ja nun nicht.



  • Hallo

    F98 schrieb:

    int sTest;
    
    ...
    
    SehrToedlicherRabiaterIntelligenterNervigerGegner stringTest;
    

    Wer seine Variablen so benennt, dem ist wahrlich nicht mehr zu helfen. Mit der selben Argumentation kann man auch andere einfache Regularien ad absurdum führen. Das ist aber eher kontraproduktiv.

    Das Problem ist doch, dass man, wenn man die Un verwendet, natürlich immer noch darauf bedacht sein sollte seinen Variablen selbsterklärende Namen zu geben. Du hast also nichts gewonnen, sondern nur noch mehr Informationen, weil du vor den Namen dann noch ein Kürzel schreiben musst. Dazu ist das Ganze noch immer Unterschiedlich (angeblich werden nur Basistypen benannt - Listen aber auch). Das passt doch alles hinten und vorne nicht. Wozu muss man eigentlich den Typ einer Variablen immer aus den Namen erkennen. Die Situationen, in denen ich nicht wusste, um welchen Datentyp es sich handelt, sind wirklich sehr selten.

    OT: Verwendet ihr eigentlich var für lokale Variablen?

    chrische



  • asc schrieb:

    Knuddlbaer schrieb:

    int sTest;

    Und schon ist der Typ klar 😉

    Genau 😉

    oder

    SehrToedlicherRabiaterIntelligenterNervigerGegner stringTest;
    

    Ja, und wo ist der Unterschied zu

    string dasIstEineIntVariable;
    

    ?

    Bei einer radikalen Typänderungen hast du mit sprechenden Namen dasselbe Problem wie mit UN (und sprechenden Namen). Lösung: STRG+SHIFT+H



  • Hallo

    Wenn man den Datentyp mit den Namen verpackt dann kann man natürlich UN nehmen, aber warum sollte man das machen? Warum ist es wichtig, dass man den Typen aus den Namen erkennen kann?

    chrische



  • is doch c# oder ?
    wer auf ein prefix besteht - soll ein "o" fuer "objekt" bekommen #gg

    int oCounter = 5;
    string oName = "blafasel";
    DateTime oBirthDay = DateTime.Now;

    #gg

    ich selber bin komplett weg von der UN {ich hatte es hier im forum auch schon verteidigt} da ich es einfach nicht mehr brauch
    nur noch _* fuer private objekt members, das wars
    find ich schnell lesbar, und man unterscheidet sofoert wo es her kommt

    int Counter = 5;
    string Name = "blafasel";
    DateTime BirthDay = DateTime.Now;
    

    also ich seh in dem beispiel kein vorteil wenn cih jeweils i, s oder dt davor schreiben wuerd

    und wie benennt man dann das?

    class Person
    {
        public Person(string name, DateTime birthDay)
        {
            ID = Voodoo();
            Name = name;
            BirthDay = birthDay;
        }
    
        public int ID { get; private set; }
        public string Name { get; private set; }
        public DateTime BirthDay { get; private set; }
    }
    

    schreibt man nun

    Person pperson = new Person("Mr Evil", new DateTime(26, 09, 1982));
    oder laesst man den bloedsin und schreibt einfach
    Person person = new Person("Mr Evil", new DateTime(26, 09, 1982));

    ich hab hier auch objekte womit ich assemblies (dll files) auslese, modifiziere, neu schreibe usw
    das ist in einen "AssemblyReader" welches von "MarshalByRefObject" ableitet
    wie soll ich dafuer ein praefix finden?

    wir sind doch wie gesagt bei c# - also wuerd ich vorschlagen bei der microsoft convention zu bleiben - einheitlich mit dem framework

    Class Member Usage Guidelines
    http://msdn.microsoft.com/en-us/library/426s83c3.aspx

    Design Guidelines for Class Library Developers
    http://msdn.microsoft.com/en-us/library/czefa0ke.aspx



  • Hallo

    o als Präfix finde ich gut.... 😃

    chrische



  • Passt!

    Tannenbaum oTannenbaum;

    :xmas1:



  • UN hat der Teufel gemacht.

    Man kann ja jetzt auch sowas schreiben:

    ...
    var vDing = GMVZahl;
    


  • Den Typ einer variablen zu erkennen ist meistens nicht das problem. Wenn man sich an die Regel hält das Funktionen nicht größer als 20 Zeilen sein sollten (idr) dann kann man die Variablendefinition meist auf einen Blick sehen auch ohen UN und Intellisense und Co. Wichtiger ist es den SINN der Variablen zu verstehen. Also sowas wie

    _ppLPDWsrc

    Ist nunmal echt wenig aussagekräftig.

    dagegen wäre

    sourceBuffer

    doch viel schneller als das zu Begreifen was es ist.

    Wenn Ihr euch fragt ob euer Codingstyle brauchbar ist... Dann stellt euch einfach mal vor Ihr müssted den Sourcecode am Telefon mit jemand besprechen der ihn gerade nicht sehen kann.

    Was glaubt ihr wäre in solch einer Situation leichter zu besprechen?

    LPCWSTR pLVWBbn = TTWA2TX(L"Hello There");

    oder

    wchat_t* textBuffer = CharToWChar("Hello There");

    Ich Wette drum das ihr die zweite Zeile NICHT buchstabieren müsst.

    In dem Zusammenhang steht auch meine Ablehnung gegen den Unterstrich am Anfang "_buffer". Versucht das mal jemandem Vorzulesen...

    Also: Unterstrich buffer plus Unterstrich eingabe = Unterstrich Ausgabe ....



  • Was hat die UN mit kryptischen, nichtssagenden Bezeichnern der Marke "_paslöf_kjsö" zu tun?! Es ist einfach falsch, das gleichzusetzen. Sowas mache ich jedenfalls nicht. Du versuchst, deine Position zu stärken, indem du der Gegenpartei einfach Dinge unterstellst...


Anmelden zum Antworten