Varibalennamen so ok?

[DennisXX]

Hi Folks !

Ich habe mal eine Frage an euch. Ist es eigentlich ok, so Variablennamen zu vergeben, oder sollte man so etwas vermeiden und anders gestalten und wenn ja, wie kann man das besser gestalten?

strVaribaleName // bei Strings
strFirstName // bei Strings
strLastName // bei Strings
intCountOfDepartment // bei Integer

usw.

Kann man das so machen?

Greetz
Dennis

 

[Marcinek]

Ja kann man so machen.

 

[DennisXX]

Und wäre es ok, so Klassennamen zu vergeben?

SQLGeneration //erster Klassenname
SQLFormGeneration //zweiter Klassenname

Greetz
Dennis

 

[mc]

Da du nur gefragt hast, ob man das machen kann: ja

Sinnvoll und empfehlenswert ist es aber nicht.

 

[Sonecc]

Da du nur gefragt hast, ob man das machen kann: ja

Sinnvoll und empfehlenswert ist es aber nicht.

Eine solche Aussage ist immer zu begründen

 

[faetzminator]

Ich würde den Datentypen rausnehmen. Einfach nur [c]firstName[/c], [c]age[/c], [c]departmentCount[/c]... Mit deiner IDE weisst du sowieso, welche Typen diese Variablen haben. Und die Datentypen sollten sowieso klar sein.

 

[Tomate_Salat]

Ich bin kein Fan von. Spätestens bei eigenen Objekten verlierst du den "Vorteil".

MyInvocationHandlerObjectFactoryExceptionHandler objMyObject; // oder sowas: myhofehObject

Die Namenslänge ist bewusst ins extrem lange gewählt. Ich würde bei aussagekräftigen Bezeichnern bleiben. Den Typ von der Variable kannst du notfalls ganz leicht über die IDE in Erfahrung bringen.

 

[jgh]

ich habe das bisher nur für GUI-Variablen so gehandhabt, dass man den Typ davor schreibt....muss aber sagen, dass ich die Idee auch bei Strings, int´s etc eigentlich recht gut finde!
Klar kann man den Typ auch schnell in einer IDE in Erfahrung bringen, auf einen Blick sieht man es aber nur so.

Bei den Klassennamen würde ich mir halt genau überlegen, ob die Klasse entsprechend der Benamung passt...also ob deine Klasse [c]SQLGeneration [/c] wirklich SQL-Statements generiert, oder ob sie eher ein Connector zu einer bspw. MySql-DB darstellt.

und wenn ich ein Objekt vom Typ [c]MyInvocationHandlerObjectFactoryExceptionHandler [/c] ...dann habe ich halt eine Instanz die [c]myInvocationHandlerObjectFactoryExceptionHandler][/c] die so heißt...auch wenn es beim coden manchmal nervig ist, lieber einen sprechenden Namen wählen, als [c]mIHOFEH[/c]

 

[Michael...]

Ist ja nicht so, dass ich andere schon darüber Gedanken gemacht haben. Deswegen der allgm. Hinweis:
Code Conventions for the Java Programming Language und Naming Conventions

Variable names should be short yet meaningful. The choice of a variable name should be mnemonic- that is, designed to indicate to the casual observer the intent of its use.

Solche Typ Präfixe würde ich weglassen, da - wenn man sich an den Naming Conventions orientiert - in den meistenFällen der (generelle) Typ aus dem Namen ableiten lässt:
numOfDepartments oder firstName lassen ja vom Namen bereits vermuten, dass es sich um eine Zahl (höchstwahrscheinlich sogar eine Ganzzahl) bzw. um einen String handelt. Wenn es dann wirklich interessant sein sollte, ob es sich um ein int oder long handelt, kann man sich das innerhalb einer Sekunde per Tooltip von der IDE anzeigen lassen.

 

[Marco13]

Das nennt sich Ungarische Notation ? Wikipedia und sollte IMHO der Vergangenheit angehören. Abgesehen davon macht es IMHO auch keinen Sinn. Es ist schwerer zu lesen, und bei sowas wie
cbNameSelection
weiß man dann DOCH wieder nicht, ob's eine CheckBox oder eine ComboBox ist...

 

[mc]

Eine solche Aussage ist immer zu begründen

Variablennamen sollten lesbar und selbsterklärend sein. Ich habe jetzt keinen Bock, Clean Code und Refactoring zu erklären. Daher : Google
Nur soviel:
1. Es ist logisch, dass eine Anzahl eine (Ganz)zahl und ein Name ein String ist. Wenn Variablennamen kryptisch sind, dann sollten sie lesbar umbenannt werden.
2. Außerdem bindest du mit diesem Benennungsschema die Variablennamen zu eng an die Implementierung. Einfaches Beispiel: IDs. Die können als Longs, Strings oder gar eigene Objekte implementiert werden. Das hat dann aber nichts im Variablennamen zu suchen.

 

[Sonecc]

Mit diesem Beitrag hast du dem TO nun deutlich mehr geholfen als mit deinem ersten

Um aber auch was konstruktives zu sagen: Mir gingen solche Bezeichner immer auf den Nerv. Ich finde sie unpraktisch und sie helfen niemanden, weder bei der Lesbarkeit, noch beim Verständnis (was ja nun schon mehrfach erwähnt wurde)