Namenskonventionen für Felder
Thomas Richter
ich suche übliche Namenkonventionen:
final fName
final static NUR_GROSSBUCHSTABEN
usw.
mfg Thomas Richter
--
Thomas Richter 'Codito ergo sum' Diplominformatiker Softwareentwickler
t...@ariva.de http://www.ariva.de
+(49) 0431/97108-27
Börse Kurse Charts Aktien Zertifikate Anleihen Fonds Devisen
Thomas Porocnik
> macht das ev. Sinn
Mist, diese unmögliche Formulierung wollte ich mir doch abgewöhnen...
Thomas Porocnik
>>
>> Schlechtestes Beispiel ist in Java Ungarische Notation zu benutzen...
> Warum?
>
Weil es den Code unleserlich macht und der Mehrwert fehlt.
Wenn man Sprachen mit z.B. Pointern benutzt, macht das ev. Sinn, aber
wenn der Compiler sowieso mosert, wenn du den falschen Typ zuweist,
braucht man das nicht.
Beim GUI-Programmieren mag das Anfügen von Typbezeichnern Sinn machen:
phoneLable, phoneTextField ...
Gruß
Thomas
Thomas Porocnik
> ich suche übliche Namenkonventionen:
>
> final fName
> final static NUR_GROSSBUCHSTABEN
> usw.
Schätze, du meinst so Art "Dekorierer" und nicht die klassischen
Konventionen.
Hm, die von dir erwähnte für "Konstanten" ist üblich, die für final
halte ich schon für überflüssig. Das einzige was ich u.U. sinnvoll halte
ist der Präfix "_" für Klassenvariablen.
Schlechtestes Beispiel ist in Java Ungarische Notation zu benutzen...
Gruß
Thomas
Florian Simon
>
> Schlechtestes Beispiel ist in Java Ungarische Notation zu benutzen...
>
Warum?
Gruß
Florian
Thomas Porocnik
>
> Also das ist, denke ich, Geschmacksache. Ich finde Code ohne Typpräfix
> an den Variablennamen furchtbar, ist aber wahrscheinlich nur
> Gewöhnungssache...
Ist doch unmöglich oder:
MyPiPaPoClass mpppcTest = ...
Florian Simon
>
> Viel schlimmer ist IMHO, dass es immernoch arg doppeldeutig bleibt:
>
> MySpiel msTest;
> MySituation msTest;
>
> oder
>
> long lTest;
> Long lTest;
>
Ihr wollt mich nicht verstehen ;-)
Wenn man es natürlich genau nach der 'reinen Le(h|e)re' macht, dann
findet man immer solch schöne Sachen:
TextBox -> tbTest
ToolBar -> tbTest
Wenn man sich aber innerhalb des Personenkreises, der damit zu tun
haben wird (Team, komplette Firma..), einig ist, finde ich sowas sehr
übersichtlich:
TextBox -> tbTest
ToolBar -> tbarTest
Auf jeden Fall besser als ToolBar1, TextBox1, ToolBar2, usw.
Gruß
Florian
Ingo R. Homann
Viel schlimmer ist IMHO, dass es immernoch arg doppeldeutig bleibt:
MySpiel msTest;
MySituation msTest;
oder
long lTest;
Long lTest;
;-(
Ciao,
Ingo
Florian Simon
> Florian Simon wrote:
>>
>>
> Weil es den Code unleserlich macht und der Mehrwert fehlt.
Also das ist, denke ich, Geschmacksache. Ich finde Code ohne Typpräfix
an den Variablennamen furchtbar, ist aber wahrscheinlich nur
Gewöhnungssache...
Gruß
Florian
Rudolf Ziegaus
>Ihr wollt mich nicht verstehen ;-)
>Wenn man es natürlich genau nach der 'reinen Le(h|e)re' macht, dann
>findet man immer solch schöne Sachen:
>TextBox -> tbTest
>ToolBar -> tbTest
>Wenn man sich aber innerhalb des Personenkreises, der damit zu tun
>haben wird (Team, komplette Firma..), einig ist, finde ich sowas sehr
>übersichtlich:
>TextBox -> tbTest
>ToolBar -> tbarTest
>
>Auf jeden Fall besser als ToolBar1, TextBox1, ToolBar2, usw.
>
>Gruß
>Florian
Na, ich neige dazu, dann gleich lieber gleich "toolbarTest" zu
schreiben. Wo es meines Erachtens größere Probleme geben kann, ist bei
den vordefinierten Typen (i für int, l ür long, etc.). Wenn da mal was
geändert werden muss (z. B. von int auf long), dann muss der Name an
allen betroffenen Stellen mitgeändert werden. Ds finde ich jetzt nicht
so toll, wenn ich den Namen an allen möglichen Stellen ändern muss,
nur weil der Typ sich geändert hat. Die Gefahr ist natürlich, dass die
Änderung unterbleibt (ob das jetzt absichtlich oder unabsichtlich
geschieht, sei jetzt mal dahin gestellt). In diesem Fall hat man dann
weniger als eine Nicht-Aussage, sondern eine Falschaussage des Namens.
Ich denke, dass die Wahrscheinlichkeit bei den elementaren Typen
größer ist als bei selbst erstellten Klassen, aber auch dort ist das
natürlich nicht auszuschließen.
Rudi
Joerg Jooss
Typpräfixe in einer Welt *polymorpher* Objekte sind sinnlos.
Cheers,
--
http://www.joergjooss.de
mailto:news-...@joergjooss.de
Oliver Specht
> Hi,
> ich suche übliche Namenkonventionen:
>
> final fName
> final static NUR_GROSSBUCHSTABEN
> usw.
>
> mfg Thomas Richter
>
http://java.sun.com/docs/codeconv/
http://www.ambysoft.com/javaCodingStandards.html
http://mindprod.com/jgloss/codingconventions.html
HTH,
Oliver
--
email: oliver ät dol2day dot com
Oliver Specht
[..]
> Typpräfixe in einer Welt *polymorpher* Objekte sind sinnlos.
>
> Cheers,
Wieso? Normalerweise weist man ein Objekt sich nicht selbst zu oder
beziehst Du Dich auf Unterklassen?
Mick Krippendorf
>
> Ich finde Code ohne Typpräfix an den Variablennamen
> furchtbar, ist aber wahrscheinlich nur Gewöhnungssache...
Ich vermute, du kennst das Unmaintainable-Code-How-To noch nicht:
http://mindprod.com/unmain.html
Gruß,
Mick.
martin demberger
Ich halte TypPrefixe für unnötig.
1. Ist im OOP-Ansatz nicht der Typ wichtig sondern die unterstützte
Schnittstelle.
2. Sollte die Sichtbarkeit einer Variable so klein sein, dass ich
jederzeit sofort die Deklaration finde.
3. Schafft man sich Probleme beim Ändern. Dann muss immer der Name
mitgeändert werden. Bei einer Umstellung von float nach double halte ich
das für unsinnig.
Die IMHO einzige Stelle an der Typprefixes sinnvoll sind, ist bei GUIs.
Auch hier wäre der Ansatz mit Interfaces sinnvoller, aber SWING und AWT
unterstützen das ja nicht... :-(
Gruß Martin
P.S. Ich halte auch Prefixes und Schreibkonventionen für Sichtbarkeiten
für unsinnig. Mich interessiert beim Implementieren nicht wo was
sichtbar ist, sondern nur die angebotene Schnittstelle. Ob der Wert
konstant oder änderbar ist, ist Aufgabe der Implementierung hinter der
Schnittstelle (oder der Deklaration) und nicht des Variablennamen.
Florian Simon
>
> Ich vermute, du kennst das Unmaintainable-Code-How-To noch nicht:
>
> http://mindprod.com/unmain.html
auf eine Art einigen muss. Wir fahren damit ganz gut... Ich kann und
will also nur für mich sprechen und ganz bestimmt niemanden 'bekehren'...
Gruß