Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
ich hab letztens ein Java-Codestück gesehen, in welchem öfters Variablennamen mit vorangestelltem Unterstrich benutzt wurden. Gibt es dafür eine Konvention, wann man das macht? Bzw was speziell dadurch gekennzeichnet wird?
Mir fehlt irgendwie das Stichwort um selbst danach zu googeln...
In der offiziellen Konvention gibts dazu nichts. Allerdings wird diese Konvention des öfteren verwendet, so auch an meiner Universität. Prinzipiell werden alle Klassenvariablen mit einem '_' angeführt.
Allerdings habe ich auch keinen Link zu einer Niederschrift. Vielleicht wissen da andere Leute mehr 😉
class Person {
private String _name;
public String getName() {
return _name;
}
public void setName(String name) {
_name = name;
}
}
Diese Vorgehensweise ist recht verbreitet, und wird dann für private Instanzvariablen verwendet. Vorteil ist IMHO: Du machst den Unterschied zwischen Instanzvariablen (die den Zustand des Objekts bestimmen) und irgendwelchen in Methoden verwendeten Hilfsvariablen und Parametern automatisch sichtbar und hast durch den Unterstrich die ganzen Instanzvariablen in gewisser Weise logisch gruppiert. Ansonsten: Der Unterstrich heißt Underscore. Google befördert dir ein paar Diskussionen dazu zutage. Manche lehnen es ab und verweisen auf Konventionen, andere finden es praktisch für die Lesbarkeit usw.
In der offiziellen Konvention gibts dazu nichts. Allerdings wird diese Konvention des öfteren verwendet, so auch an meiner Universität. Prinzipiell werden alle Klassenvariablen mit einem '_' angeführt.
Allerdings habe ich auch keinen Link zu einer Niederschrift. Vielleicht wissen da andere Leute mehr 😉
... A similar convention exists for the underscore character; while it's technically legal to begin your variable's name with "_", this practice is discouraged. ...
kommt auch aus dem Dokument und besagt das ebenfalls. Dennoch kenne ich so einige Leute, auch Personen aus größeren Firmen, die underscores voranstellen.
Da muss man für sich selbst entscheiden, ob man das machen möchte. Ich persönlich finde es ja schöner und leserlicher, das mag aber auch Gewohnheit sein.
Selbst ohne IDE ist das hinfällig. Schließlich sollten Methoden so lang sein, dass sie locker auf eine Bildschirmseite passen. Da hat man alle lokalen Variablen auch ohne Einfärbung schnell im Blick.
Verwandt ist auch die Konvention [c]m_[/c] vor Instanzvariablennamen zu schreiben. Bei Jetty wird das z. B. gemacht.
Es wundert mich schon, dass die militanten Verfechter der Coding guidelines noch nichts getippt haben. 😀
In Java wird offiziell nichts vorangesetzt ausser this.
Gerade letzte Woche gefunden:
Java:
private int zaehler;
public void machWas(int zaehler) {
this.zaehler = zaehler;
// dann kommt ziemlich viel Code
// zaehler wird einige male neu gesetzt und verwendet
// "einNeuerInteger" wird berechnet
int einNeuerInteger = 42;
// als zweitunterste Zeile
zaehler = einNeuerInteger;
}
Warum nur wir zaehler nicht neu gesetzt? aehm welcher zaehler? 😉
Mein System ist da leicht anders. (Es war in den meisten Projekten so oder ähnlich vorgeschrieben)
Regel 1: Es darf keine zwei gleichen Namen innerhalb eines Namespaces geben (die Verwechslungsgefahr ist zu gross)
Regel 2: Es darf keine zwei gleichen Namen ...... 🙂
Regel 3: Es gibt keine Ausnahmen für 1 und 2
Regel 4: Es gibt keine weiteren Regeln als 1 - 3
Ok , soweit die karikierte Widergabe der Regeln, welche durch ganz wenige Ausnahmen bestätigt wurden.
Parameter: pMeinWert
Variable: mMeinWert (m = Member)
Prozedurlokale Variablen: ohne führende Buchstaben oder allenfalls mit l (kleinem L) für lokal
Man darf natürlich kreativer sein und unterschiedliche Bezeichnungen wählen, aber es soll immer ersichtlich sein, WAS eine Variable oder ein Parameter beinhalten, also sollten sie auch ähnlich Namen haben.
Was definitv unnötig ist, ist es den Typ auch noch in den Variablennamen zu packen - das ist nur in Sprachen nötig, die kein echtes Typenkonzept haben.
Stimmt - man sucht lieber Fehler wie den oben beschriebenen ;-) Ich möchte die IDE sehen, die dabei hilft. (Ach ich habe eine Regel vergessen - Parameter dürfen nie als Variablen missbraucht werden)
Ausserdem "man" - wer will denn schon "man" sein - kreative Genies haben sich schon immer von den Anderen unterschieden 😀 Hm - warum qualmt es hier plötzlich so ???:L
Was ich allerdings militant vertrete ist, dass Militanz selten was bringt :lol: Das Einzige was etwas bringt ist, mögliche Fehler schon im Ansatz zu verhindern und das wiederum meine ich ernst.
Ganz einfach: Halte dich an die Konventionen, dazu gehört u.a. das Parameter als final deklariert werden, dann schafft das sogar der Compiler, ganz ohne IDE.
Stimmt - man sucht lieber Fehler wie den oben beschriebenen ;-) Ich möchte die IDE sehen, die dabei hilft. (Ach ich habe eine Regel vergessen - Parameter dürfen nie als Variablen missbraucht werden)
Viel schlimmer als einem Parameter einen neuen Wert zuzuweisen ist der oft auftretende Fehler, dass man eine lokale Variable wie eine Instanzvariable nennt und dann das "this" vergisst. Nennt man Name Hiding und z.B. Checkstyle kann das erkennen und meckern. Allerdings schlaegt das dann auch bei jedem Setter an. Deshalb koennte man den Underscore vor alle Instanzvariablen schreiben.
Ich seh da kein Problem, man sollte es einfach nur in einem Projekt einheitlich machen.
in Eclipse übrigens auch eine Warnung, und bei Parametern nicht, also nicht störend,
da Instanzvariablen auch anders dargestellt sind erübrigt sich das eigentlich ziemlich
Es gab bei einigen Eclipse/RCP-Projekten (Eclipse Plugins und so) früher mal die Konvention, Membervariablen mit einem Unterstrich zu beginnen, aber inzwischen gilt auch dort, dass man das NICHT mehr machen sollte.
Der einzige Fehler den du beschreibst sind deine eigenen Konventionen.
Ganz einfach: Halte dich an die Konventionen, dazu gehört u.a. das Parameter als final deklariert werden, dann schafft das sogar der Compiler, ganz ohne IDE.
So jetzt nervst du mich definitv! Ob da nun Moderator dran steht oder nicht interessiert mich einen Sch....
Wenn Java etwas Sinnbefreites wie das verändern von Parametern zulässt wird das mit 100% Sicherheit von irgendeinem Programmierer auch ausgenutzt - ausserdem war es nicht mein Code.
Es sind auch nicht MEINE Konventionen, ich bin nur im Laufe der Jahre zur Überzeugung gekommen, dass die gut sind. Es sind die Konventionen renomierter Firmen in denen ich gearbeitet habe und interessanterweise waren die in den meisten Fällen sehr ähnlich (Nein, Namen nenne ich keine, das habe ich nicht nötig) und in diese Firmen ist insgesamt wesentlich mehr Erfahrung vorhanden als alle Member hier zusammengezählt haben.
Und wie in den alten Zeiten: Ich ignoriere diesen Thread - Komentare erübrigen sich also
siehe Einstellungs-Screenshot,
gibt weitere Optionen, alle evtl. interesant,
gegebenfalls nur in neueren Versionen verfügbar, ich habe gerade Version: 1.3.0.20100617-0520, Helios,
nicht die neueste,
edit:
eine weitere Option erzwingt das Schreiben von this.attribut, noch deutlicher, obwohl mir die gesonderte Anzeige reicht, lauter this. verschandeln
Wenn Java etwas Sinnbefreites wie das verändern von Parametern zulässt wird das mit 100% Sicherheit von irgendeinem Programmierer auch ausgenutzt - ausserdem war es nicht mein Code.
Es sind auch nicht MEINE Konventionen, ich bin nur im Laufe der Jahre zur Überzeugung gekommen, dass die gut sind. Es sind die Konventionen renomierter Firmen in denen ich gearbeitet habe und interessanterweise waren die in den meisten Fällen sehr ähnlich (Nein, Namen nenne ich keine, das habe ich nicht nötig) und in diese Firmen ist insgesamt wesentlich mehr Erfahrung vorhanden als alle Member hier zusammengezählt haben.
Der ein oder andere hier sollte sich mal wieder einkriegen und beide sollten mal wieder vom Grundschulniveau runterkommen....:autsch:
In meiner Firma wird (leider) das von Andi_CH vorgeschlagene System verwendet:
pName für Parameter
mName für Member
nervt mich tierisch, ist aber nunmal so.
Was Eclipse betrifft, so färbt Eclipse Member automatisch in blau ein. Damit kann man super erkennen, ob es die richtige Variable war.
Ich selbst bin also im Endeffekt dafür dass irgendwelche Prefixe zu unterlassen sind und stattdessen this verwendet werden sollte.
Der Context ist damit leichter zu erkennen und die Variablennamen sind weniger kryptisch.
Nun, das hätte eine interessante Diskussion über das Für und Wider der this-Konvention und ihrer Vor- und Nachteile gegenüber dem Underscoring werden können. Einfach mal einen Schritt zur Seite gehen, und gemeinsam abseits von ausgetretenen Pfaden die eigenen Best Practices reflektieren. Stattdessen werden von der "Wider"-Fraktion die Nutzer dieser Vorgehensweise pauschal als Idioten verunglimpft, und jegliche Diskussion mit dem Hinweis auf eine wie in Stein gemeißelte Konvention erstickt. Schade, aber es gibt zum Glück mehr als genug Stellen, an denen sowas gesittet und niveauvoll diskutiert werden kann und bereits wurde. Komischerweise ist das im englischen Sprachraum und akademischen Umfeld stets problemlos möglich. Das gibt einem über den Horizont macher Teilnehmer hier schon zu denken. Nur noch soviel:
1. Sollte meiner Meinung nach die Lesbarkeit von Quellcode primär eine Eigenschaft des Quellcodes sein, und nicht abhängig von der konkreten Implementierung einer bestimmten IDE sein.
2. Sind nach der Logik mancher Betonköpfe hier also auch Leute wie Martin Fowler Idioten, welche noch nicht mal mit ihrer IDE umgehen können? Schließlich verwendete er schon beide Konventionen.
Wie gesagt, ich vertrete die Meinung dass Leute die _, m und andere Präfixe verwenden ihre IDE nicht richtig bedienen können, um genau zu sein: Sie arbeiten gegen ihre IDE.
Ok, manche Leute werden gezwungen Präfixe zu nutzen, obwohl sie es besser wissen...
Autom. generieren von Getter & Setter ist damit nicht möglich, die Code Completion funzt auch nicht wirklich gut, wenn ich _ eintippe, bekomme ich alle Member Variablen zur Auswahl, je länger die Präfixe um so weniger gut funzt das dann.
Wenn man jetzt noch die anderen, nicht offiziellen Best Practices dazunimmt (Klassen sollten eigentlich nie länger als 250 Zeilen sein, Methoden so kurz wie möglich, nie über 4-5 Zeilen ausser man nutzt ein switch/case) wird man schnell einsehen dass die Präfixe aus einer Zeit stammen, als das alles noch nicht so war und eine IDE nichts weiter war als ein Texteditor war von dem man den Compiler aus starten konnte, denn wenn man eben so programmiert wie es sich zur Zeit als Best Practice darstellt, dann braucht man keine Präfixe.
Falls man dann noch Parameter als final deklariert (Konvention), entdeckt eben sogar ein Compiler von der Kommandozeile aus Probleme.
Bessere Lesbarkeit für nicht IDE Nutzer und damit weniger Lesbarkeit/Funktionalität für IDE nutzer?
Sorry, aberr Code liest man eben am besten/häufigsten in der IDE, nicht in Notepad... hier den kleinsten gemeinsamen Nenner zu finden heisst das IDE Nutzer Nachteile hätten, macht IMHO wenig Sinn wenn man bedenkt was das für die Produktivität bedeutet, man sollte sich nciht einreden dass diese 2 Wege, also mit und ohne IDE, gleichwertig sind.
Ich wäre interessiert daran zu sehen, wo Martin Fowler in den letzten 5 Jahren Code geschrieben hat der präfixe für Variablen nutzte, nicht vergessen: Sogar ein Kent Beck war mal der Überzeugung, dass checked Exceptions eine gute Sache sind, bis er seine Meinung geändert hatte, niemand ist absolut frei von Irrtum.
Autom. generieren von Getter & Setter ist damit nicht möglich, die Code Completion funzt auch nicht wirklich gut, wenn ich _ eintippe, bekomme ich alle Member Variablen zur Auswahl, je länger die Präfixe um so weniger gut funzt das dann.
Doch ist es. Eclipse kann wunderbar eingestellt werden, damit es erkennt, dass solche variablen einen Unterstrich haben. Damit gehen Getter & Setter wunderbar 🙂
Wenn du '_' eintippst und dann alle Membervariablen bekommst, ist das nicht weiter schlimm, denn du musst dann eben den zweiten Buchstaben noch eintippen, damit hast du dann die selbe Auswahl, als hättest du keinen Präfix. Nebenbei durch eintippen von '_' fallen auch alle Methoden, die Eclipse (je nach Einstellung) auch anbieten würde, weg.
Bessere Lesbarkeit für nicht IDE Nutzer und damit weniger Lesbarkeit/Funktionalität für IDE nutzer?
Sorry, aberr Code liest man eben am besten/häufigsten in der IDE, nicht in Notepad... hier den kleinsten gemeinsamen Nenner zu finden heisst das IDE Nutzer Nachteile hätten, macht IMHO wenig Sinn wenn man bedenkt was das für die Produktivität bedeutet, man sollte sich nciht einreden dass diese 2 Wege, also mit und ohne IDE, gleichwertig sind.
"_myVar" ist doch nicht schlechter lesbar als "myVar". Den Vorteil, den ich da sehe ist, dass ich automatisch sehe, dass es eine Membervariable ist. Das ist weder umständlicher zu lesen, noch ist das sonderlich großer Aufwand.
Doch ist es. Eclipse kann wunderbar eingestellt werden, damit es erkennt, dass solche variablen einen Unterstrich haben. Damit gehen Getter & Setter wunderbar
Sicher, Eclipse bietet die Möglichkeit das zu konfigurieren, die anderen IDEs auch? 😉
Warum eigentlich nicht "Convention over Configuration" folgen, ist auch eine Best Practise (im gegensatz zu Präfixen)?
Wenn du '_' eintippst und dann alle Membervariablen bekommst, ist das nicht weiter schlimm, denn du musst dann eben den zweiten Buchstaben noch eintippen, damit hast du dann die selbe Auswahl, als hättest du keinen Präfix. Nebenbei durch eintippen von '_' fallen auch alle Methoden, die Eclipse (je nach Einstellung) auch anbieten würde, weg.
Dann müsstest du doch einsehen, das 2 Buchstaben tippen mehr Aufwand ist als einen einzigen einzutippen, genauso wie es mehr Aufwand bedeutet die IDE erst umzukonfigurieren von den allemeinen Konventionen.
"_myVar" ist doch nicht schlechter lesbar als "myVar". Den Vorteil, den ich da sehe ist, dass ich automatisch sehe, dass es eine Membervariable ist. Das ist weder umständlicher zu lesen, noch ist das sonderlich großer Aufwand.
IMHO ist das schon umständlicher zu lesen.
Welche Präfixe gibt es, um private, protected, package private und public Methoden zu "markieren"?
Gar keine? Ist das etwa inkonsistent? 😉
Dazu kommt, dass der mögliche Vorteil der Unterscheidung zwischen Variablen und Methoden auch wegfällt wenn die Klassen kurz & knackig bleiben. Und übrigens, eine IDE verwendet auch andere Symbole/Farben für Variablen und Methoden, genauso wie für vershiedene Sichtbarkeiten
Was sind denn die angeblichen Vorteile von Präfixen?
- Man sieht ob es sich um ein Member handelt -> Das sieht man in allen IDEs sowieso, also kein Vorteil IMHO.
Ich verstehe diesen Vorteil immer noch nicht...
den _ sollten wir schon deshalb nicht für Eigenschaften verwenden, weil dann die Introspection nicht funktioniert. Wenn das aber ausdrücklich gewünscht wird, könnten wir einen _ vor die Zugangsmethode machen. Z.B. versteckt [c]_getBirthdate()[/c] die Eigenschaft "birthdate" vor der Introspection, gewährt aber trotzdem noch Zugang für Eingeweihte.
Andis Beispiel ist bisschen ungluecklich und trifft das eigentliche Problem nicht. Hier mal was die IDE nicht als Fehler erkennen kann:
Java:
public class FooBar {
private fooBar;
public void doIt( int foo ) {
int fooBar = 0;
fooBar += foo;
doFancyStuff( fooBar );
}
}
Konventionen sind doch dazu da, um es so schwer wie moeglich zu machen, aus Versehen Fehler zu schreiben - klar, wenn man keine Fehler macht, braucht man natuerlich auch keinerlei Konventionen. Und wenn man jahrelang (meinetwegen auch in anderen Sprachen) sein Blick auf nen Underscore vs kein Underscore trainiert hat und nicht auf fett gedruckt vs nicht fett gedruckt, dann ist das imho eine sinnvolle Konvention. Zudem ist "_" deutlich kuerzer als ein "this." und aehnlich funktioniert das auch in anderen Sprachen (z.B. schreibt man in Ruby ein "@" vor eine Instanzvariable).
Ich denke mal, das die Konventionen neben der Fehlervermeidung auch noch den Zweck verfolgen ein Einheitsdesign zu erschaffen um den "modernen Javaprogger" zum Teamplayer zu machen.
Wenn man also nicht gerade wie Sonecc auf Arbeit gezwungen wird anders zu arbeiten, sollte man seinen inneren Schweinehund mal überwinden und zum Nutzen aller die Konventionen benutzen, sonst sind die nix wert und ich hab Mist gelernt ^^
ich lerne jetzt seit einem jahr java in meiner firma, ich habe das hier von anfang an gemäß konventionen und mit ide gelernt. alle anderen genannten vorschläge/methoden halte ich auch für total überflüssig wenn seine ide bedienen kann und sauber programmiert. ich hatte ne menge probleme, aber noch nie wegen lokal vs member vs parameter
