Schreibweise von Membervariablen
-
Knuddlbaer schrieb:
Um das Problem mit dem "lockeren" Compiler zu lösen, würde ich ihn einfach so scharf schalten, dass er eben sowas nicht mehr durchgehen lässt und ALLE Programmierer sozusagen dazu zwingt, 'this' zu benutzen!
Wie soll er das erzwingen können ?
Wenn man ohne 'this' nicht kompilieren kann, muss man zwangsläufig 'this' hinschreiben...^^
oder ich hab deine Frage nicht verstanden!
Grüße
-
class Klasse { private int feld = 0; int TuWas() { int feld = 1; return feld + 1; } }Erklär mir mal wie du hier erzwingen willst, dass man 'this' benutzen muss.
Klar, man könnte sagen lokale Veriablen dürfen nicht den gleichen Namen wie eine Membervariable haben, allerdings finde ich das keine gute Lösung.PS: Auch beim _-Anstatz meckert der Compiler nicht, allerdings ist imho schneller ersichtlich ob es sich um eine lokale oder eine Membervariable handelt, da diese Information Teil des Variablennamens ist.
-
O.o schrieb:
Klar, man könnte sagen lokale Veriablen dürfen nicht den gleichen Namen wie eine Membervariable haben, allerdings finde ich das keine gute Lösung.
Hehe, wusste gar nicht, dass das so geht :-P! Ob man dies erlaubt oder nicht, darüber lässt sich meines Erachtens streiten!
Aber in dem Fall ist es klar, da hast du recht.Trotzdem bleibe ich dabei, dass man 'this' immer benutzen sollte. Es schaut einfach besser aus und signalisiert gleich die Klassenzugehörigkeit!
Grüße
-
Hehe, wusste gar nicht, dass das so geht :-P!
Darum dreht es sich doch aber IMHO. Würde das nicht gehen, hätte man das Problem möglicherweise falscher Zuweisungen nicht.
-
Also ich habe lieber ein "m_" vor der Variable, als sie im Editor z.B. kursiv lesen zu müssen. Farben sind ja 'ne tolle Sache. Allerdings gibt es zu wenige Farben, die sich untereinander stark unterscheiden und einen guten Kontrast zu Weiß bilden, um alles damit erschlagen zu können. Fettdruck finde ich schon irgendwie komisch, und kursive Schrift im Code ist imo abartig! Zumindest bei mir beginnen da die Schwierigkeiten, den Code schnell lesen zu können, und nicht bei einigen, wenigen Präfixen...
-
Allerdings gibt es zu wenige Farben, die sich untereinander stark unterscheiden und einen guten Kontrast zu Weiß bilden, um alles damit erschlagen zu können.
Genau das finde ich auch.
Deswegen fände ich es praktisch wenn die IDE vielleicht irgendwelche Symbole einblenden könnte. Vor oder über/unter dem Bezeichner. Müsste man experimentieren was am besten lesbar ist und am wenigsten ablenkt.Praktisch fände ich evtl. wenn man auch die Hintergrundfarbe pro "Typ" umstellen könnte.
Aber naja, zuerst bräuchte ich mal eine IDE die zuverlässig und schnell erkennt um was es sich bei einem Bezeichner handelt. Auch in grossen Programmen mit viel Namensräumen, auch wenn man ADL verwendet, auch wenn Templates im Spiel sind... nicht so einfach
-
hustbaer schrieb:
Deswegen fände ich es praktisch wenn die IDE vielleicht irgendwelche Symbole einblenden könnte. Vor oder über/unter dem Bezeichner. Müsste man experimentieren was am besten lesbar ist und am wenigsten ablenkt.
Hört sich im Grunde gar nicht schlecht an. Trotzdem würde ich da erst mal Angst haben, dass sich der Screen vor lauter Mini-Symbolen in eines dieser Bildchen verwandelt, auf denen man angeblich was sieht, wenn man lange genug auf einen imaginären Punkt dahinter starrt.
Sowas steht und fällt eben mit der Umsetzung...
-
Meine Definition erfolgt so:
public class Test1 { private double _dValue = 0.0; private string _sCaption = string.empty; public double Value { get { return _dValue; } } public string Caption { get { return _sCaption; } } public Test1(double dValue, string sCaption) { _dValue = dValue; _sCaption = sCaption; } }Privates mit Unterstrich, Publics als Property und lokale Variablen immer ohne Unterstrich. So weis man bescheid.
-
aber mit _d oder _s ? sieht ja grausig aus
-
Meine im Gegenvergleich so (was glaube ich auch die C# Empfehlung ist):
public class Test1 { private double number = 0.0; private string caption = string.empty; public double Number { get { return number; } } public string Caption { get { return caption; } } public Test1(double number, string caption) { this.number = number; this.caption = caption; } }Ich sehe keinen Vorteil mehr am "m_" und vergleichbaren, und von der UN (wie von F98 präferiert) bin ich noch länger weg. Wenn man nicht mehr ersehen kann was lokale Variablen und was Membervariablen sind, ist dies ein eindeutiges Indiz für zu lange Funktionen.
-
Hm, das mit dem this ist schon ein Argument, ich persönlich finde es mit dem _ besser. Aber das kann man sehen wie Nolte, der sah es wie er wollte.
-
Hier mal meine Version:
public class Test1 { private double p_Number = 0.0; private string p_Caption = string.empty; public double Number { get { return p_Number; } } public string Caption { get { return p_Caption; } } public Test1(double number, string caption) { Number = number; Caption = caption; } }Membervariablen, Klassennamen immer großgeschrieben, Parameter, lokale Variablen immer klein angefangen (glaub nennt sich camelCase?). Private Member immer mit p_ davor.
-
Noch so einer, der die Klammer "{" immer oben hinmacht
-
Jo, gleich schon viel übersichtlicher, gell?
Im Ernst: es gibt keinen einleuchtenden Grund, die schließende Klammer eines Blocks NICHT auf einer Ebene und ohne Füllzeile mit der "blockverursachenden" Zeile zu setzen.
void Blockverursacher() { ^ //----- Kommentar statt unnützer Füllzeile, sprich "{", ftw. ;) . int blubber = 0; . ... . ... . ... . ... }Bitte beachten: die obige Formatierung ist die Alleinseeligmachende. :xmas1:
-
Hallo
@F98: Wie machst du das, wenn es sich um eigene Klassen, Listen oder Dictionaries handelt? Wie benennst du dann die Variablen?
chrische
-
Und weil ich auch mitmachen will beim Beispiel zeigen
, in C# mach ich es derzeit so:public class Test1 { public double Number { get { return _number; } // einzeilige Form nur bei simplen "return _x" Gettern bzw. "_x = value" Settern } public string Caption { get { return _caption; } } public Test1(double number, string caption) { // Kommentare kann man auch hier schreiben ohne eine Zeile zu verschenken ;) _caption = caption; _number = number; } private double _number = 0.0; private string _caption = ""; }
-
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; } public class CHastenichtGesehen { #region Enums public enum EType { Type1, Type2 } #endregion #region Vars private int _iValue = 0; private EType _eType = Type1; private List<SIrgendwas> _liIrgendwas = new List<SIrgendwas>(); #endregion #region Properties public int Value { get { return _iValue; } set { _iValue = value; } } public EType Type { get { return _eType; } set { _eType = value; } } #endregion public CHastenichtGesehen() { } }"Klammer oben" finde ich unübersichtlich und es verstößt gegen Gestaltungsgrundsätze (Gesetz der Geschlossenheit).
@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.
-
hustbaer schrieb:
Und weil ich auch mitmachen will beim Beispiel zeigen
, in C# mach ich es derzeit so:[...] public Test1(double number, string caption) { // Kommentare kann man auch hier schreiben ohne eine Zeile zu verschenken ;) [...]Andersrum wird ein Schuh draus: die Zeile ist nur dann nicht völlig sinnlos verschenkt, WENN man einen sinnvollen Kommentar darin setzt. D.h. bei dieser Variante herrscht Kommentarpflicht und grauenhaft aus sieht's auch noch.
-
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.
-
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.
