Namenskonventionen für Objekt-Attribute

[Teejott]

Hallo zusammen,

Ich entwerf mal kurz ein Beispielszenario zu meiner Fragestellung:
Ich habe eine Klasse "Person", und eine Klasse "Team", die mehrere Personen über eine Containerklasse aufnimmt.

Nun haben sowohl Person als auch Team ein Attribut name:

class Person {
  String name;
  ...
}

class Team {
  String name;
  ...
}

Nun kam von einem Mitarbeiter der Vorwurf, das wäre zu leicht zu verwechseln, und sollte doch lieber so aussehen:

class Person {
  String personName;
  ...
}

class Team {
  String teamName;
  ...
}

Das widerspricht etwas meinem Verständnis der Objektorientierung, denn welcher Name gemeint ist, wird ja bereits deutlich dadurch, zu welcher Klasse das Attribut gehört. Wenn ich das noch in den Attributnamen reinnehme, ist die Information redundant, und wenn ich die Klasse mal umbenenne hab ich auch keine Freude daran. Für mich spricht also alles für die erste Variante.

Interessant wäre es jetzt allerdings, ob es dazu eine Konvention (in Java) gibt, welche der beiden Varianten zu benutzen ist, oder ob man sonst irgendwo nachlesen kann, warum eine der beiden Varianten unbedingt der anderen vorzuziehen ist. Falls es sowas gibt, würde ich in der Dokumentation gerne darauf verweisen.

Viele Grüße,
Thomas

 

[ARadauer]

hier gehts jetzt nur um die Benennung oder?

dass man Attribute normalerweise private setzt und über public getter und setter verfügbar macht, ist dir bewusst oder?

Also ich finde es ist Geschmackssache, es spricht nix dageben, teamName zu verwenden. Mich würde es aber auch nicht stören, wenn jemand nur name verwendet...

Generell zu sagen, das man immer vor ein Attirubtt den Klassennamen schreiben soll, halte ich aber niciht für sinnvoll.

 

[sliwalker]

Hoi,

das schreibt Java Dir nicht so genau vor.
Hier mal der Auszug zu den CodingConvetions:

http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367


Einerseits hat dein mitarbeiter Recht. Andererseits aber auch Du.
Das muss man aber im Kontext betrachten. Wenn Du jetzt gerade mit den Klassen unheimlich viel an einer Stelle machen musst und es wirlich "oft" zu Verwechselungen kommen kann, dann würde ich mir überlegen, den Klassennamen mit reinzunehmen.
Nicht weil mir das wer vorschreibt, sondern weil es dann einfacher zu programmieren und warten ist.

Grundsätzlich würde ich es aber nicht machen. Auch aus den Gründen die Du schon genannt hast. Da ich viel mit Variablen machen muss, die zum selben Themengebiet ehören, aber oft unterschiedliche Typen haben können, stelle ich meist noch die abgekürzte Form des Typs voran.

i - Integer
n - Number (int)
bln - Boolean
str - String

Habe mich dran gewöhnt und finde es auch gut, wobei es oft stört. Zum Beispiel beim generieren von Gettern und Settern.
"getStrName()" sieht halt kacke aus. Die Regel (ungarische Notation) ist entstanden, als man noch kein IDEs hatte, die mit Syntaxhighligthing und der gleichen aufwarten konnten. Trotzdem benutze ich es, weil ich so den Typ sehen kann ohne auf das Popup zu warten.

Es ist halt eine Absprachesache und muss in den Kontext passen. Wichtig ist nur, dass alle das Gleiche machen, so dass Code einheitlicher gestaltet wird.

Im Normalfalls sieht man am Objektnamen ja schon, zu was "name" gehört. Da ist es halt wichtig die Objekte vernünftig zu benennen "heimTeam", "gastTeam", "currentPerson" usw...

Bei Deinem Beispiel wäre ein teamName nicht unsinnvoll, weil es ja nunmal der name eines teams ist: also ein teamName.

Aber wie gesagt. Absprachesache, Geschmackssache usw....

greetz
SLi

 

[Marco13]

Ich bevorzuge auch die erste Lösung. Frag' deinen Mitarbeiter mal, in welchem Zusammenhang das "leicht zu verwechseln" wäre. Es wäre nur leicht zu verwechseln, wenn man irgendwas hat wie
String akutellerName = x.getName();
das ist dann aber nicht die schuld desjenigen, der die Methode "getName" statt "getTeamName" genannt hat, sondern desjenigen, der die Variable "x" und nicht "team" genannt hat. Sowas wie
String akutellerName = team.getTeamName();
fände ich auch blöd - Redundanz ist immer redundant.

 

[sliwalker]

Redundanz ist immer redundant.

Wie wahr, wie wahr... :meld:
*G*

Nichtredundante Redunzanz ist auch schwer zu produzieren

 

[Marco13]

So als Nachtrag und Nebenbemerkung: Diese "ungarische Notation" finde ich persönlich und ganz subjektiv grauenhaft :autsch:

Viele kennen vermutlich diese Sduite enier Elingshcen Unvirestiät, luat der es eagl ist, in wlehcer Rienhnelfoge die Bcuhtsbaen in eniem Wrot sethen. Das stimmt so zwar NICHT (das merkt man, wenn man die Reihenfolge mal ein bißchen mehr durcheinanderwürfelt), aber trotzdem kann man als Mensch erstaunlich gut Texte lesen, solange (die Reihenfolge der Buchstaben einigermaßen stimmt und) alle Buchstaben vorhanden sind!.
Durch die fehlenden Buchstaben (meistens: fehlenden Vokale) kann man die Namen einfach nichtmehr so schnell und durch einen Blick erfassen. Man muss sie Buchstabe-Für-Buchstabe "parsen", "interpretieren" und sich überlegen, was die Abkürzung heißen soll, und bei solchen Variablennamen wie "cbOption", weiß man dann DOCH wieder nicht, ob es eine CheckBox oder ComboBox ist :roll:

Ich finde, Variablennamen können ruhig das beschreiben, was sie beschreiben: Statt "cbOption" kann sich doch die Mühe machen und "optionComboBox" schreiben.

Aber vermutlich ist das auch Ansichtssache :roll:

 

[maki]

Nun kam von einem Mitarbeiter der Vorwurf, das wäre zu leicht zu verwechseln, und sollte doch lieber so aussehen:

Der Mitarbeiter sollte sich besser konzentrieren, um Verwechslungen auszuschliessen

Sorry, aber wenn die schon in Unterschiedlichen Klassen sind... mehr kann man doch nicht machen um Verwechslungen auszuschliessen.

Ansonsten:
http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

 

[maki]

i - Integer
n - Number (int)
bln - Boolean
str - String

Sorry, aber das ist Müll.. hungarian.. Kotz..

 

[ARadauer]

ich muss maki und marco zustimmen, sich sehe wenig sinn darin, ein i for eine zahl zu schreiben.
normalerweise ist es klar, das ein Name ein String und ein Preis ein double ist. Und mit Eclipse ist die Unterstützung so mächtig, dass ich die Buchstaben vor den Variablen nur als stören empfinde.

 

[sliwalker]

Hoi,

so argumentiert ein Kollege von mir auch und ich lasse ihm ja, und auch euch, seine Meinung. Möchte nochmal betonen, dass es nicht zu 100% nützlich und sinnvoll ist, aaaber....

... es hat durchaus seine Daseinberechtigung.
Gut es stammt aus einer zeit, wo man es brauchte, aber ich denke immer, dass die Variable nackt ist, wenn ich es weglasse. hat sich so eingebrannt.

Das heißt nicht das ich restlos alles so schreibe, aber gerade wenn ich unterscheiden will, ob es ein Integer Objekt ist oder ein primitivier Typ, dann schreibe ich es davor.
Ich mag es auch, wenn in Vorschlagslisten alle gleichen Typen untereinander stehen, weil ich dann nur das Kürzel des Typs tippen brauche um zum Ziel zu gelangen.

Gut, bei "optionCheckBox" würden alle Variablen des gleichen Themengebiets untereinander stehen. Fänd ich jetzt auch nicht schlecht. Ist glaube ich Angewohnheitssache und durch die Konvetion in meiner Firma komme ich auch net drumrum.

Mir fallen nicht viele Argumente dafür ein, merke ich gerade, weshalb ich da wohl nochmal drüber nachdenken werde
Also ich würdet eine Variable einfach ganz nackt und schnörkellos: "String name" nennen?

Ich glaube daran könnte ich mich nicht gewöhnen. Das sieht aus wie hingeschissen..ups sorry.. Wie jemand der sich keine Gedanken dazu gemacht hat, wie Variablen benannt werden...rein subjektiv. gerdae die Kamel-Schreibweise hat es mir angetan, deshalb komme ich wohl auch anscheinend so gut mit "strName" zurecht.

Naja...
...so wild ist das Thema ja auch wieder nicht.
ich lasse es erstmal so, ich schreibe es gerne so

greetz
SLi

 

[maki]

Die Hungarian Notation stammt von MS...

Das Problem mit der Hungarian Notation:
Die Präfixe können lügen.

Wer mal mit der WIN32 API gearbeitet hat, weiss wie gefährlich es ist, sich auf das w am Anfang des Variablennamens zu verlassen.
Statt einem wordhatte man nämlich später den Typ zum double word gemacht, konnte aber natürlich die (öffentliche) API nicht mehr ändern...

Redundanz birgt diese Gefahr immer, deswegen ist es auch ein "No-No" in Java laut offiziellem Style Guide

Es gibt auch keine Vorteile sie zu nutzen, diese Zeiten sind endgültig vorbei

 

[Janus]

ich mag ungarische notation überhaupt nicht. ich finde, solcher code ist schwer zu lesen. sie mag ihre berechtigung gehabt haben in c89, als man u.U. noch jedesmal 500 zeilen nach oben scrollen musste, um eine variablendeklaration zu finden. aber heutzutage hat sie null berechtigung mehr. eindeutige bezeichner sind wesentlich besser geeignet, für verständlichen code zu sorgen.

einen aspekt der ungarischen notation finde ich aber immer noch gut: prefixes die kennzeichen, was semantisch in einem typen steckt und logisch geordnete bezeichner.

String specialString = specialFromRaw( rawString );
// statt
String str = raw2Special( in );

 

[Wildcard]

Die Hungarian Notation stammt von MS...

Nein, tut sie nicht. Sie stammt von Charles Simonyi und wurde von MS erstmals im großen Stile angewandt (wenn auch nicht richtig).
Mich wundert, dass das noch niemand hier eingeworfen hat, aber auch ihr redet nicht von der echten ungarischen Notation, sondern von genau jenem Microsoft Irrtum.
Es ging nie um den Datentyp, sondern die Art der Variable (was sie tut).
Wenn ich mal wieder Wiki zitieren darf:

Durch diese Zweideutigkeit existieren zwei Strömungen der Ungarischen Notation, das Apps Hungarian, welches die echte Notation im Sinne Simonyis ist, und das Systems Hungarian, welches durch die Fehlinterpretation der Microsoft’schen Betriebssystemabteilung entstanden ist. Letzteres ist für den schlechten Ruf der Konvention verantwortlich, weil die Benennung einer Variablen nach dem Datentyp wenig zum Verständnis des Inhalts beiträgt und trotzdem viel Aufwand verursacht.

http://de.wikipedia.org/wiki/Ungarische_Notation