Schreibweise von Membervariablen

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

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

Hallo

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

chrische

Passt!

Tannenbaum oTannenbaum;

:xmas1:

bja

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

_matze

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

Hallo

Schau dir mal die WinAPI an: Das soll UN sein und ist verdammt kryptisch. Am meisten stört mich aber, dass eben kein gleiches Verhalten angewandt wird. Basistypen werden benannt, Listen auch, aber eigenen Klassen nicht. Das ist doch Mist.

chrische

_matze schrieb:

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

Ach, unterstellen... soso..

Dann halt realte Beispiele: Windows SDK V6.1 (Aka, nichts davon in der Liste ist erfunden, alles copy/paste)

g_pGB;
g_pMC;
g_pMP;
g_pME;
g_pMEE;
pFSrc
pCTR
pvi
ddsd
pbS
pbD
d3dlr
pmk

Und das war jetzt nur aus einem kleinen Sourcefile. Jetzt das Ratespiel, wofür steht das?

_matze

Na ja, die ersten paar sind globale Pointer!

Meine Frage gilt weiterhin: was hat die UN mit solch kryptischen Bezeichnern zu tun? Die ist lediglich für den Präfix "g_p" verantwortlich, nicht für das nachstehende Kauderwelsch. Wie gesagt, UN enthebt einen nicht von der Verantwortung, halbwegs aussagekräftige Namen zu vergeben. Deine Beispiele sind Müll, da hast du ganz Recht. Das liegt aber nicht an der UN, sondern an dem anderen Teil des jeweiligen Namens...

F98

Das ist genau das, was ich weiter vorne schon meinte. Ihr führt hier krasse Beispiele auf, um ein simples und funktionierendes Prinzip zu demontieren. Blos weil paar Bremser ihre Variablen nicht richtig benennen können, heißt das noch lange nicht, dass das Prinzip falsch ist. Diese Leute würde auch mit jedem anderen Prinzip ihre Variablen falsch benennen.

asc

F98 schrieb:

Blos weil paar Bremser ihre Variablen nicht richtig benennen können, heißt das noch lange nicht, dass das Prinzip falsch ist.

Ich habe dennoch im Code ein "anzahlEintraege" lieber als ein "iAnzahlEintraege", alleine schon weil ich ersteres ohne im Lesefluss stoppen zu müssen lesen kann. Für letzteres muss ich erst einmal zusätzlich wissen für was das i steht, wirklich Mehrinformationen erhalte ich daraus nicht.
Wie heißt es so schön: "Man liest häufiger Code, als das man ihn schreibt".

Zudem hasse ich es wegen Typänderungen gleich die Bezeichner ändern zu müssen, wenn sie das gleiche machen wie vorher. Beispielsweise wenn ich aufgrund des Wertebereiches eine Anpassung machen muss, ändert dies nichts an der Funktion der Variable.

Zudem: Wir leben in einer Zeit in der die objektorientierte, sowie generische Programmierung, gang und gäbe ist. Spätestens hier kann man keine festen (Meiner Meinung nach: kryptischen) Präfixe mehr einsetzen. Einerseits weil die Typen zunehmen und zum zweiten weil man die Typen teilweise garnicht mehr bestimmen kann.

Wo liegt also der Sinn in diesen Präfixen?

cu André

F98

asc schrieb:

Ich habe dennoch im Code ein "anzahlEintraege" lieber als ein "iAnzahlEintraege", alleine schon weil ich ersteres ohne im Lesefluss stoppen zu müssen lesen kann. Für letzteres muss ich erst einmal zusätzlich wissen für was das i steht, wirklich Mehrinformationen erhalte ich daraus nicht.

Wo ist das Problem, bei einer lokalen Variable den Namen iCount oder iElementCount zu wählen. Global braucht man solche Variablen/Namen sowieso nicht, da Listen (List) eh ihre eigenen Properties namens Count haben.

asc schrieb:

Zudem hasse ich es wegen Typänderungen gleich die Bezeichner ändern zu müssen, wenn sie das gleiche machen wie vorher. Beispielsweise wenn ich aufgrund des Wertebereiches eine Anpassung machen muss, ändert dies nichts an der Funktion der Variable.

Wie oft änderst Du in Deinem Code die Typen aufgrund des Wertebereiches? Das ist doch eher ein Hinweis auf konzeptionelle Mängel und hat nichts mit den Namen an sich zu tun. Außerdem ändert man doch keine Strings in int oder double, sondern bleibt in einer ähnlichen Typkategorie (float/double, int/unsigned int ...).

asc schrieb:

Zudem: Wir leben in einer Zeit in der die objektorientierte, sowie generische Programmierung, gang und gäbe ist. Spätestens hier kann man keine festen (Meiner Meinung nach: kryptischen) Präfixe mehr einsetzen.

Hier stimme ich Dir zu, meine Verfahrensweise habe ich schon paar Einträge vorher erläutert.

asc schrieb:

Einerseits weil die Typen zunehmen und zum zweiten weil man die Typen teilweise garnicht mehr bestimmen kann.

Man muss hierbei sicherlich unterscheiden:

1. Basistypen: int, double ...
2. höhere Basistypen: List ...
3. abstrakte Typen: XMLParser-Klassen, Netzwerk-Klassen ...

Wobei jedes seine Funktion hat und sich nicht alles mit "Objekt o" erledigen lässt und ich dabei u.U. Probleme im Bezug auf den Kontext bekomme.

asc

F98 schrieb:

Wo ist das Problem, bei einer lokalen Variable den Namen iCount oder iElementCount zu wählen. Global braucht man solche Variablen/Namen sowieso nicht, da Listen (List) eh ihre eigenen Properties namens Count haben.

Ich habe hier einfach irgendeinen Bezeichner genommen, mach dich nicht am Count/Anzahl fest. Das gilt unabhängig von der Variable.

F98 schrieb:

asc schrieb:

Zudem hasse ich es wegen Typänderungen gleich die Bezeichner ändern zu müssen, wenn sie das gleiche machen wie vorher. Beispielsweise wenn ich aufgrund des Wertebereiches eine Anpassung machen muss, ändert dies nichts an der Funktion der Variable.

Wie oft änderst Du in Deinem Code die Typen aufgrund des Wertebereiches? Das ist doch eher ein Hinweis auf konzeptionelle Mängel und hat nichts mit den Namen an sich zu tun. Außerdem ändert man doch keine Strings in int oder double, sondern bleibt in einer ähnlichen Typkategorie (float/double, int/unsigned int ...).

"Konzeptionelle Mängel" bekommst du immer wenn ein Kunde nachträglich etwas geändert haben will. Oder wenn man erst nur ein Land betrachtet, und dann wegen Internationalisierung ändere Datentypen verwenden muss. Die Frage ist, ob dies überhaupt unter "Konzeptionelle Mängel" fällt. Es sind Änderungen am Iterativen Softwareentwurf (Nicht jede Software wird in dem Sinne "fertig" das sie beim Kunden läuft, sondern über Jahre hinweg gepflegt und angepasst).

F98 schrieb:

asc schrieb:

Einerseits weil die Typen zunehmen und zum zweiten weil man die Typen teilweise garnicht mehr bestimmen kann.

Man muss hierbei sicherlich unterscheiden:

1. Basistypen: int, double ...
2. höhere Basistypen: List ...
3. abstrakte Typen: XMLParser-Klassen, Netzwerk-Klassen ...

Wieso muss ich hier unterscheiden? Warum Sonderfälle schaffen?
Ich bin ein Fan davon alles was möglich ist, zu vereinheitlichen. Um so weniger Sonderfälle es gibt, um so leichter kommen auch neue Programmierer in einen Projekt klar.

cu André

So, genug über die Ungarische Notation und irgendwelche Präfixe diskutiert. Ich mach hier mal zu.

Thread geschlossen.

Hallo

asc schrieb:

F98 schrieb:

asc schrieb:

Einerseits weil die Typen zunehmen und zum zweiten weil man die Typen teilweise garnicht mehr bestimmen kann.

Man muss hierbei sicherlich unterscheiden:

1. Basistypen: int, double ...
2. höhere Basistypen: List ...
3. abstrakte Typen: XMLParser-Klassen, Netzwerk-Klassen ...

Wieso muss ich hier unterscheiden? Warum Sonderfälle schaffen?
Ich bin ein Fan davon alles was möglich ist, zu vereinheitlichen. Um so weniger Sonderfälle es gibt, um so leichter kommen auch neue Programmierer in einen Projekt klar.

cu André

Genau das ist doch die Kardinalsfrage, um die ihr euch die ganze Zeit drückt? Warum Sonderfälle schaffen?

chrische

F98

Um zu trennen, zu ordnen.

Also wir benennen auf der Arbeit die Membervariablen immer "my_name" und die Paramter einer Funktion "_name"