ungarische Notation in java?
Albert Uerz
weiß jemand, wo ich vernünftige Richtlinien für die Wahl der Bezeichner
(Klasse, Attribute, Methoden) finde?
Albert
Joachim Sauer
ob sie vernünftig sind, muß jeder selbst entscheiden, aber auf
http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html findet man
das offizielle Statement von Sun zu dem Thema.
Auf jeden Fall haben die den Vorteil halbwegs akzeptiert zu sein und
bilden quasi den kleinsten Gemeinsamen nenner.
> Albert
mfg
Joachim Sauer
--
Hungarian Notation is the tactical nuclear weapon of source code
obfuscation techniques
- http://mindprod.com/unmainnaming.html
Thomas Porocnik
"Albert Uerz" <ue...@pvschwarz.de> schrieb im Newsbeitrag
news:3D578D2F...@pvschwarz.de...
>weiß jemand, wo ich vernünftige Richtlinien für die Wahl der >Bezeichner
>(Klasse, Attribute, Methoden) finde?
Also die ungarische Notation würde ich nicht benutzen. Das hat zwar so einen
systematischen Touch, ist aber m.E. sehr schwer zu lesen.
Wenn wirklich zur Unterscheidung der Typ im Variablennamen stehen soll, dann
so: "value" vs. "valueString"
Einige interessante Argumente zu dem Thema findet man hier:
http://c2.com/cgi/wiki?SystemOfNames
Gruß
Thomas
Georg Stahl
1) Die schon geposteten "Coding Conventions" von Sun.
2) http://mindprod.com/unmainnaming.html Punkt 29
3) Du legst eine Variable vom Typ java.util.List an. Dieser Variablen
ordnest du ein Objekt vom Typ java.util.Vector zu. Wie willst du nun
Variable benennen, bzw. von welchem Typ ist die Variable (probiere
System.out.println( <variable> instancof <List | Vector | Collection |
AbstractList | ...>) und zähle wie oft du "true" siehst).
aus 2) und 3) folgt für mich: ungarische Notation hat in Java nichts zu
suchen (bzw. dient nur zur "unleserlichmachung" von Code).
Georg
Thomas Stets
Eigentlich hat sich der Gebrauch der ungarischen Notation in Java
nicht durchgesetzt.
Ich persönlich halte sie für überflüssig und eher störend. (Aber das
sollte jeder selbst entscheiden). In Java haben die Variablen normalerweise
einen so kleinen Sichtbarkeitsbereich, dass man IMO darauf verzichten kann.
In den Java-Projekten, an denen ich mitgearbeitet habe (bis ca. 300.000 LOC)
habe ich sie nicht vermisst.
mfg Thomas
Roman Seibold
Hallo,
von mir auch noch ein bißchen...
Wie Du aus den anderen Antworten bereits gesehen hast,
ist die ungarische Notation in Java nicht sonderlich beliebt.
In C++ hat sie durchaus eine gewisse Daseinsberechtigung,
da dort einiges an unterschiedlichen Typen "rumschwirrt"
(structs, unions, classes, pointer etc.)
In Java ist es eigentlich einfach: entweder ich habe eine
Referenz oder ich habe einen elementaren Typ. Punkt.
Wenn man noch Klassen-, Instanz- und lokale Variable
unterscheiden will, so kann man das auch mit "Java-Bordmitteln"
tun:
this.attribut
Klassenname.klassenattribut
lokaleVariable
Mehr braucht man zum Codeverständnis in Java wirklich nicht.
(Vielleicht noch das Agreement, mit this.xyz nicht auf statische
Variable zuzugreifen...)
Gruß,
Roman
--
________________________________________________________________________
Roman Seibold, Dipl.-Inform.
Haenchen & Partner, Beratungsgesellschaft fuer Wirtschaftsinformatik mbH
Calwer Str. 1, 71034 Boeblingen, Germany
Schulungen, Coaching, Projekte im Java-Umfeld
Roman....@haenchen.softwarezentrum.de
http://www.haenchen.softwarezentrum.de
Phone: +49 (0)7031 2126 100
FAX: +49 (0)7031 2126 199
________________________________________________________________________
Niklas Weiß
versuchs mal mit:
http://softwaredev.earthweb.com/article/1,,615891,00.html
http://www4.ncsu.edu:8030/~moriedl/projects/hungarian/
http://www.crazy-team.at/ctnet/englisch/beginnercourse/jc0701.htm
http://www.kclee.com/clemens/java/CCLJavaCodingStandard.html
http://cime.net/java/coding_recommendations.html
http://www.soft.uni-linz.ac.at/Teaching/Begleitmaterial/Ubungsangaben/SE2/SEUE3.php
HTH, Niklas.
Sönke Müller-Lund
> http://softwaredev.earthweb.com/article/1,,615891,00.html
> http://www4.ncsu.edu:8030/~moriedl/projects/hungarian/
> http://www.crazy-team.at/ctnet/englisch/beginnercourse/jc0701.htm
> http://www.kclee.com/clemens/java/CCLJavaCodingStandard.html
> http://cime.net/java/coding_recommendations.html
> http://www.soft.uni-linz.ac.at/Teaching/Begleitmaterial/Ubungsangaben/SE2/SEUE3.php
alles Links, denen man besser nicht folgen sollte.
Wenn Leute ihr Design verpfuschen, glauben sie, mit Ungarischer Notation
selbiges retten zu können.
Oder anders ausgedrückt:
Wenn Du meinst, die Ungarische Notation kann dir in Java helfen, dann
überdenke lieber dein Design.
Sönke
Albert Uerz
>
> Wenn Leute ihr Design verpfuschen, glauben sie, mit Ungarischer Notation
> selbiges retten zu können.
> Oder anders ausgedrückt:
> Wenn Du meinst, die Ungarische Notation kann dir in Java helfen, dann
> überdenke lieber dein Design.
ohoho, sei nicht so polemisch. Hier geht es weder um Design noch um bedingungslose
Verwendung der Ungarischen Notation sondern allein um die Fragestellung, ob es Literatur
jedeweder Art gibt, wo genau der Einsatz derselbigen diskutiert wird, will heißen: wenn
ja, wie sie in Java aussehen könnte.Wenn nein, welche Gründe dagegen sprechen. In diesem
Thread wurden schon einige Argumente geliefert, die wirklich zum Nachdenken aufforden,
ohne gleich in eine verbale Defäkation überzugehen.
Albert
Albert Uerz
vielen Dank für die Hinweise
Albert
Albert Uerz
>
> Wenn Leute ihr Design verpfuschen, glauben sie, mit Ungarischer Notation
> selbiges retten zu können.
> Oder anders ausgedrückt:
> Wenn Du meinst, die Ungarische Notation kann dir in Java helfen, dann
> überdenke lieber dein Design.
ohoho, sei nicht so polemisch. Hier geht es weder um Design noch um
bedingungslose
Verwendung der Ungarischen Notation sondern allein um die Fragestellung,
ob es Literatur
jedeweder Art gibt, wo genau der Einsatz derselbigen diskutiert wird,
will heißen: wenn
ja, wie sie in Java aussehen könnte.Wenn nein, welche Gründe dagegen
sprechen. In diesem
Thread wurden schon einige Argumente geliefert, die wirklich zum
Nachdenken auffordern,
Thomas Bensler
> Hi Sönke,
>
>
>>Wenn Leute ihr Design verpfuschen, glauben sie, mit Ungarischer Notation
>>selbiges retten zu können.
>
>>Oder anders ausgedrückt:
>>Wenn Du meinst, die Ungarische Notation kann dir in Java helfen, dann
>>überdenke lieber dein Design.
>
> ohne gleich in eine verbale Defäkation überzugehen.
"verbale Defäkation" ist aber was anderes.
Ciao, Thomas.
Sönke Müller-Lund
> In diesem
> Thread wurden schon einige Argumente geliefert, die wirklich zum Nachdenken aufforden,
> ohne gleich in eine verbale Defäkation überzugehen.
"verbale Defäkation"?
Ich habe mich doch nahezu sachlich zum Thema UN geäussert.
Sönke
Stefan Matthias Aust
http://mindprod.com/unmainnaming.html (Abschnitt 29ff) empfehlen.
Ich persönlich sehe nicht, warum ich Variablennamen einen Typ aufdrücken
muss der einzig das Ändern der Variable (man stelle sich den Aufwand
vor, wenn ich statt float fValue jetzt doch lieber double benutzen
möchte...) erschwert oder (wenn man das f nicht in ein d ändert sondern
so läßt) dazu dient, den Leser zu verwirren. Ein Programm sollte so
einfach wie möglich selbst sein, und da helfen IMHO allgegenwärtige
Kürzel wie lpsz nicht gerade.
Da aber keine Regel ohne Ausnahme ist, bei UIs benutze ich schon mal
txtVorname und lblVorname usw.
> http://softwaredev.earthweb.com/article/1,,615891,00.html
> http://www4.ncsu.edu:8030/~moriedl/projects/hungarian/
> http://www.crazy-team.at/ctnet/englisch/beginnercourse/jc0701.htm
Ich glaube, es wurde schon mal gesagt, das obiger Kurs nicht der
Weisheit letzter Schluss ist. Ratschläge wie etwa, variablen immer am
Methodenanfang zu definieren statt - wie es wesentlich sinnvoller wäre -
den Einsatzbereich einer Variable zu klein wie möglich zu halten und
damit diese erst z.B. in der Schleife zu deklarieren
for (int i = 0; i <...)
Object o = ....
statt
int i;
Object o;
...
for (i = 0; ...
o = ...
> http://www.kclee.com/clemens/java/CCLJavaCodingStandard.html
Dieser "clemens" meint, dass Enumeration, Object, Hashtable und noch ein
paar ausgewählte Objekte so speziell sind, dass sie andere präfixe
kennen sollten, als die restlichen Fußtruppen-Objekte, die einfach ein
"p" (wie passend) bekommen. Hm, ich frage mich nur, was macht er wohl
bei ArrayList? Auch ein v wie Vector oder doch ein e wie egal...
> http://cime.net/java/coding_recommendations.html
Hier schlägt jemand vor, nur primitive Typen zu verunstalten (meine
Wertung, sorry) und Namen von Objekt-enthaltenden Variablen so zu
lassen. Man muss doch den Graben zwischen primitiven Typen und Objekten
nicht noch größer machen als notwendig. Was, wenn man int doch in
BigInteger umwandeln muss? Alles umbenennen?
bye
--
Stefan Matthias Aust
www.3plus4software.de // Inter Deum Et Diabolum Semper Musica Est
Aljoscha Rittner
> Zum Thema (Un)sinn von präfixtypen an Variablennamen kann ich nur
> http://mindprod.com/unmainnaming.html (Abschnitt 29ff) empfehlen.
>
> Ich persönlich sehe nicht, warum ich Variablennamen einen Typ aufdrücken
> muss der einzig das Ändern der Variable (man stelle sich den Aufwand
> vor, wenn ich statt float fValue jetzt doch lieber double benutzen
> möchte...) erschwert oder (wenn man das f nicht in ein d ändert sondern
> so läßt) dazu dient, den Leser zu verwirren. Ein Programm sollte so
> einfach wie möglich selbst sein, und da helfen IMHO allgegenwärtige
> Kürzel wie lpsz nicht gerade.
*g* - die Diskussion kommt immer wieder, nicht wahr? Zwar könnte ich
jetzt ein Refactoring-Tool gegenstellen und behaupten, dass es nicht
schwierig ist Variablennamen zu ändern, aber dann würde ich meiner
eigenen Überzeugung widersprechen.
Was man nämlich häufig sieht: Wenn ein Tool nicht komplett automatisch
funktioniert, wird es von Programmierern nicht immer zu 100% benutzt.
Also werden immer Präfix-Artefakte übrigbleiben. Und die verwirren
wirklich.
> Da aber keine Regel ohne Ausnahme ist, bei UIs benutze ich schon mal
> txtVorname und lblVorname usw.
Jepp, bei UIs mache ich es auch so, weil es teilweise nicht anders
geht und es von den modernen GUI-Builder einfach nicht anders zu
machen ist. Und auch da Unterscheide ich nicht mal zwischen JTextArea
und JTextField (auch egal welcher Eingabeformate) - sie erhalten alle
das gleiche Präfix. Zu häufig muß ich im GUI mal die Komponente
austauschen, weil plötzlich der Kunde meint, eine Zeile würde reichen
oder er wolle auf einmal Romane da rein schreiben.
Gruß,
Josch.
--
Einige Tags in de.comp.lang.java ( siehe http://www.dclj.de/dcljstart.html )
[INFO] - Allgemeine Infos, z.B. Links auf Webseiten - keine Frage
[DISCUSSION] - Diskussion zu einem Java-spezifischen Thema - keine Frage
[ANNOUNCE] - Vorstellung neuer Software (möglichst nicht Kommerziell)
Peter Dunkel
ich kenne die ungarische Notation von Sprachen mit einem begrenzten
Vorrat an Variablen-Typen, insbesondere wenn fehlerhafte Zuweisungen
zur Compilzeit nicht auffallen.
Java hat einen unbegrenzten Vorrat an Variablen-Typen, jede Klasse ist
ja ein Typ. Will man hier etwas sinnvolles machen, müsste man den
Namen der Klasse als Präfix des Instanz-Namens verwenden.
mfg Peter
Frank Haefemeier
> Ich glaube, es wurde schon mal gesagt, das obiger Kurs nicht der
> Weisheit letzter Schluss ist. Ratschläge wie etwa, variablen immer am
> Methodenanfang zu definieren statt - wie es wesentlich sinnvoller wäre -
> den Einsatzbereich einer Variable zu klein wie möglich zu halten und
> damit diese erst z.B. in der Schleife zu deklarieren
>
> for (int i = 0; i <...)
> Object o = ....
>
> statt
>
> int i;
> Object o;
> ...
> for (i = 0; ...
> o = ...
Hierzu hätte ich mal eine Verständnisfrage: Gibt es im Laufzeitverhalten
ein Unterschied, ob die Variable innerhalb oder außerhalb der Schleife deklariert
wird? Macht der Compiler das insofern korrekt, daß er die Variable nur einmal anlegt
und nicht bei jedem Schleifendurchlauf?
Tschau
Frank Häfemeier
Stefan Matthias Aust
> Hierzu hätte ich mal eine Verständnisfrage: Gibt es im Laufzeitverhalten
> ein Unterschied, ob die Variable innerhalb oder außerhalb der Schleife deklariert
> wird? Macht der Compiler das insofern korrekt, daß er die Variable nur einmal anlegt
> und nicht bei jedem Schleifendurchlauf?
Das Laufzeitverhalten ist gleich bzw. besser (bei später und unmittelbar
definierten Variablen). Entscheidend besser ist das Verständnis. Ich
würde Variablendefinition und Wertzuweisung *immer* kombinieren. Man
muss nicht schauen, was wohl eine Variable für einen Typ hat, sondern
mal sieht es unmittelbar auf einen Blick.
String name = "sma";
Der Compiler legt gar keine Variablen an, sondern das macht das
Laufzeitsystem. Du meist aber wahrscheinlich, ob da irgendwie bei jedem
Schleifendurchlauf activation records (aka stackframes) mit
entsprechendem Platz angelegt werden oder nicht. Java wird das
optimieren und nur einmal für den Platz sorgen. Tatsächlich kann sogar
besser optimiert werden, da bei
for (...) {
Object o = ...
}
for (...) {
Object o = ...
}
in beiden Fällen für "o" der selbe Platz im activation record
wiederverwendet wird. Hieraus resultiert dann auch unter Umständen eine
Performance-Verbesserung. Speichert man richtig große Objekte in den
Variablen (sagen wir einmal new Object[1000000]) dann würde das Objekt
wie ein schwer bekömmliches Nahrungsmittel im Magen der
Speicherverwaltung liegen. Je eher dieser Slot wiederverwendet wird und
somit das Objekt stirbt, desto besser kann der GC das verdauen.
bye
--
Stefan Matthias Aust //
Paul Ebermann
> > for (int i = 0; i <...)
> > Object o = ....
> >
> > statt
> >
> > int i;
> > Object o;
> > ...
> > for (i = 0; ...
> > o = ...
>
> Hierzu hätte ich mal eine Verständnisfrage: Gibt es im Laufzeitverhalten
> ein Unterschied, ob die Variable innerhalb oder außerhalb der Schleife deklariert
> wird?
Nein. Es sei denn, du benutzt einen arg verbogenen Compiler,
oder einen, der schlecht optimiert, dann ist sogar die zweite
Variante schlechter.
> Macht der Compiler das insofern korrekt, daß er die Variable nur einmal anlegt
> und nicht bei jedem Schleifendurchlauf?
Der Compiler legt überhaupt keine Variablen dynamisch an.
Die (lokalen) Variablen werden (falls du die Java-VM nutzt)
auf "Register" im Stack-Frame abgebildet.
Der Bytecode kann auf die einzelnen Register lesend bzw.
schreibend zugreifen (auf die ersten paar dabei mit
kürzeren Befehlen).
Gute Compiler verwenden solche Register auch für eine
andere Variable weiter, sofern die beiden Variablen nie
parallel benutzt werden.
Paul
Holger Hoffstaette
> Hierzu hätte ich mal eine Verständnisfrage: Gibt es im Laufzeitverhalten
> ein Unterschied, ob die Variable innerhalb oder außerhalb der Schleife deklariert
> wird? Macht der Compiler das insofern korrekt, daß er die Variable nur einmal anlegt
> und nicht bei jedem Schleifendurchlauf?
Nein, der Laufzeit ist das egal - es wird nur eine Variable angelegt.
Was gar nicht egal ist, ist die Sichtbarkeit: wenn außerhalb der
Schleife deklariert wird, könntest Du hinterher noch drauf zugreifen.
Das ist manchmal sinnvoll (für das Ergebnis von Berechnungen), aber für
die Laufvariable nur in den seltensten Fällen.
Wenn hinter der Schleife noch mehr Code kommt, der ebenfalls die
Schleifenvariable benutzt, kann es zu Überlappungen kommen - wenn z.B.
vor der Wiederenutzung nicht korrekt initialisiert wird, aber die erste
Schleife mit einem Fehler abgebrochen ist und der Zähler nicht da
steht, wo er soll. Das hineinziehen der Variable in den Block verhindert
dies. M.a.W.: Variablen sollten so wenig sichtbar wie möglich sein,
Ausnahmen bestätigen die Regel. :)
Holger
Frank Haefemeier
> Frank Haefemeier wrote:
>
[ sachkundige und interessante Info gelöscht]
Vielen Dank für die Erklärung. Werde ich wohl mein
verhalten in diesem Punkt ändern.
Man muß ja flexible und anpassungsfähig sein;-)
Tschau
Frank