Schreibweise von Membervariablen

[SolidOffline]

F98 schrieb:

chrische5 schrieb:

Hallo

@F98: Wie machst du das, wenn es sich um eigene Klassen, Listen oder Dictionaries handelt? Wie benennst du dann die Variablen?

chrische

public struct SIrgendwas
{
    public int iValue;
    public string sCaption;
}
[...]

"Klammer oben" finde ich unübersichtlich und es verstößt gegen Gestaltungsgrundsätze (Gesetz der Geschlossenheit).

Ja, nee, is klar.

@hustbär:

Prinzipiell gehe ich mit, ich finde aber, dass Variablentypen schon mit als Präfix in den Namen gehören, so, dass man auf Anhieb sieht, welchen Typs die Variablen sind.

Also IMO ist dein Ansatz ein gutes Beispiel dafür, wie man es NICHT machen sollte - und damit meine ich jetzt nicht die Position der geschweiften Klammern. Der Lese- und Verständnisfluss wird extrem eingebremst, wenn in Gedanken bei jedem Namen ein S, ein i, ein C, usw. abziehen muss. Ganz davon abgesehen, dass es völlig sinnlos und überflüssig ist.

[_matze]

SolidOffline schrieb:

Der Lese- und Verständnisfluss wird extrem eingebremst, wenn in Gedanken bei jedem Namen ein S, ein i, ein C, usw. abziehen muss. Ganz davon abgesehen, dass es völlig sinnlos und überflüssig ist.

So ein Quatsch! Wenn du persönliche diese Art der Notation nicht magst, ist das ok. Aber stell es nicht als 'völlig nutzlos' hin, nur weil du persönlich den Lesefluss nicht leisten kannst, da dich schon kleinste Präfixe offenbar schon verwirren. Ich meine, was passiert denn da? Verschwimmt der ganze Variablenname plötzlich? Die Trennung von Präfix und Bezeichner wird doch durch Groß-/Kleinschreibung vollzogen und ist imho deutlich genug! Und der Nutzen liegt doch auf der Hand: du siehst den Typ einer Variable, ohne dir den Tooltip deiner IDE holen zu müssen (Maus in die Hand nehmen, Maus bewegen...), und das eben auch außerhalb deiner bzw. überhaupt einer IDE. Persönliche Vorlieben sind in Ordnung, der eine mag es, der andere nicht. Aber der UN jedweden Sinn abzusprechen, ist doch etwas übertrieben. Die Frage ist lediglich, ob einem dieser Nutzen wichtig ist, und ob die negative Nebenerscheinungen für einen persönlich überwiegen oder nicht.

[F98]

SolidOffline schrieb:

Ja, nee, is klar.

Hätte schon gedacht, das sowas klar ist. Hier nochmal zum klarwerden: http://www.webmasterpro.de/design/article/gesetz-der-geschlossenheit.html

Gestaltungsgrundsätze beziehen sich nicht nur auf Dialoge. Es geht auch hier um die Wahrnehmung best. zusammengehöriger (Achtung: geschlossener; noch genauer: in (symmetrische) Klammern gesetzter) Codeabschnitte. Hintereinander gehackter, ASCII-Kauderwelsch ist nun mal schlecht lesbar. Dazu gehört meiner Meinung nach auch Klammer auf+zu auf unterschiedlichen Ebenen. Klingt bissel nach Goldwaage, ist aber so.

SolidOffline schrieb:

Der Lese- und Verständnisfluss wird extrem eingebremst, wenn in Gedanken bei jedem Namen ein S, ein i, ein C, usw. abziehen muss. Ganz davon abgesehen, dass es völlig sinnlos und überflüssig ist.

Der Lesefluss wird bei Deiner Methode sicherlich weniger gebremst, wohl aber das Verständnis. Ich muss nämlich jedesmal nachschauen, was die Variable für einen Typ hat. Besonders bei größeren Funktionen ist das schwierig.

Es läßt sich nunmal nicht alles in 1000 unübersichtliche Minifunktionen zerhacken:

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.

[asc]

F98 schrieb:

SolidOffline schrieb:

Der Lese- und Verständnisfluss wird extrem eingebremst, wenn in Gedanken bei jedem Namen ein S, ein i, ein C, usw. abziehen muss. Ganz davon abgesehen, dass es völlig sinnlos und überflüssig ist.

Der Lesefluss wird bei Deiner Methode sicherlich weniger gebremst, wohl aber das Verständnis. Ich muss nämlich jedesmal nachschauen, was die Variable für einen Typ hat. Besonders bei größeren Funktionen ist das schwierig.

So? Also muss man statt dessen irgendwo ein Präfixlexikon haben, um den Sinn zu verstehen. Damit tun sich gerade neue Programmierer schwer, zudem bringe ich wieder mal meine zwei Standardargumente:
a) Wenn man den Typ wirklich braucht, so bekommt man diesen von jeder sinnvollen IDE auch geliefert
b) Präfixe haben immer das Problem: Wo ist die Grenze zu ziehen, und wie hilfreich sind sie wirklich? Wenn man sich die kryptischen Präfixkolonnen in der WinAPI anschaut, merkt man schon bald das man effektiv eine zweite Sprache eingeführt hat die man zusätzlich merken muss.

Wenn es wichtig ist, das sich ein Wert um eine Zahl handelt, dann schreib ich es aus. Wenn ich einen bool habe, so habe ich auch eine Form des Präfixes, aber eine wo man keine Abkürzungen lernen muss. Ich empfinde etwas wie "if(isEmpty)" als lesbarer als "if(fEmpty)", "if(bEmpty)"...

Ich ziehe Code vor, den selbst ein Außenstehender mit ein wenig logischen Grundverständnis verstehen kann. Und ich habe dazu mal ein kleines Experiment gemacht. 20 an sich verständliche Zeilen eines UN-Anhängers in meine Art gebracht, und beides einen Nicht-Programmierer vorgelegt. Dieser konnte mit meinen Code mehr anfangen, und blieb auch weniger hängen.

Schreib wie du willst, nur selbst Microsoft ist (zum Glück) mit guten Grund davon abgegangen...

cu André

[SolidOffline]

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.

[SolidOffline]

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.

[F98]

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.

[Gast]

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

[_matze]

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!

[Knuddlbaer]

int sTest;

Und schon ist der Typ klar

[asc]

Knuddlbaer schrieb:

int sTest;

Und schon ist der Typ klar

Genau

oder

SehrToedlicherRabiaterIntelligenterNervigerGegner stringTest;

[F98]

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.

[asc]

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

[F98]

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.

[F98]

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.

[Gast]

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

[_matze]

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

[Gast]

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

[EXDW]

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

[Gast]

Hallo

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

chrische