Software Entwicklung

Diskutiere Software Entwicklung im Allgemeine Java-Themen Bereich.
Kirby_Sike

Kirby_Sike

Also ich hatte letzte Woche mal etwas mit meinem Dozenten gequatscht und er hatte mir erzählt, dass als er noch Softwareentwicklung gemacht hat, es „konvention“ war variablen mit datentyp präfix zu bennen. Also z.B so:


Java:
private int iAge;
private char cLetter;
private double dBill;
Macht man das immernoch und sollte ich mir das frühzeitig angewöhnen? :)
 
Kirby_Sike

Kirby_Sike

Ich deutet das mal als ein „bist du verrückt, dass ist uralt“ xD
 
M

M.L.

Ein Teil der Konzepte kann ja auch Sinn haben, z.B. bei dynamisch typisierten Programmiersprachen (wenn man raten darf, welchen Datentyp eine Variable hat) oder "m_" bei C/C++, da eine Variable/Funktion dort gerade nicht zwingend Bestandteil einer Klasse sein muss.
 
L

LimDul

Aus dem Bereich Clean-Code:
It’s not necessary to use Hungarian Notation or other type encodings
It is no longer necessary to use the Hungarian Notation as the IDE enforces types thus most errors are detected before compile type and it makes it easier to change the type of the variable if the name does not include the type. For example, we have the variable: String phoneNumberInt and the variable type has changed to String but the variable name implies that it’s an int.

Also ein klares "Nein, macht man nicht mehr".
 
QU3LLC0D3

QU3LLC0D3

Also das kenne ich zum Teil auch noch ...
Java:
final String sVorname = "Horst";
An sich finde ich das ganz persönlich auf der einen Seite ganz gut, weil es eben nicht immer aus dem Kontext ersichtlich ist um welchen Typ es sich im weiteren Verlauf handelt.

ABER die Verwendung von Gettern & Settern (und auch z.B. bei der Verwendung von Lombok) ist das Ganze dann schon ganz schnell echt ekelhaft.

So wird dann nämlich aus dem "sVorname" plötzlich
Java:
private String getSvorname() {
  return this.sVorname;
}
Das macht es dann irgendwann wieder total unübersichtlich und auch unsinnig.

Bei der Verwendung von Arrays oder Listen kann das Ganze dann aber in totalem Wahnsinn enden und am Ende wird da auch keiner mehr wirklich durchblicken können.

Daher plädiere ich auch hier zur Verwendung von sprechenden Variablen im Sinne des CleanCode-Gedanken. Das ein Vorname in der Regel ein String sein dürfte sollte klar sein. Und eine Liste von Vornamen einfach listVorname oder eben einfach vornamenListe zu nennen, macht es dann auch überflüssig dies irgendwie zu kommentieren oder kennzeichnen zu müssen.
 
mrBrown

mrBrown

Also das kenne ich zum Teil auch noch ...
Java:
final String sVorname = "Horst";
An sich finde ich das ganz persönlich auf der einen Seite ganz gut, weil es eben nicht immer aus dem Kontext ersichtlich ist um welchen Typ es sich im weiteren Verlauf handelt.
Das Problem ist vor allem auch, das es keinen Standard gibt. Für jeden mit Android-Hintergrund ist das ein statischer String...

Und eine Liste von Vornamen einfach listVorname oder eben einfach vornamenListe zu nennen, macht es dann auch überflüssig dies irgendwie zu kommentieren oder kennzeichnen zu müssen.
Oder einfach bei Listen den Plural nutzen, vornamen, das ist dann noch sprechender und enthält nicht wieder den Typ.
 
L

LimDul

Das Hauptziel sollte sein, dass der Code möglichst gut lesbar ist und keine Überraschungen enthält.

Dementsprechend würde ich bei Feldern es wirklich mehr oder minder verbieten den Typ mit in den Namen zu schreiben.
Und auch sonst würde ich es vermeiden wollen, weil es meist keinen Mehrwert bringt. Entweder wird der Typ aus dem Kontext klar, wenn ich es lese. Oder ich arbeite damit - dann sagt mir die IDE das. Wenn ich den Code lese, der Typ zum Verständnis wichtig ist, aber er aus dem Code nicht hervorgeht, dann sollte man zuerst sich fragen, ob der Code so wie er ist, sinnvoll ist und ob man den nicht besser schreiben kann. Den Typ in den Namen reinzukodieren wäre nur die letzte Möglichkeit.

Wo ich es teilweise für sinnvoll halte, wenn ich in einer Funktion konvertierungen von/nach String mache - also das gleiche fachliche Attribut einmal in seinem "nativen" Typ (z.B. LocalDate) habe und einmal in seiner String-Darstellung. Da finde ich es ok, wenn ich neben "beginnDatum" dann eine lokale Variable "beginnDatumString" habe um die klar bei lesen voneinander zu trennen. Das wäre für mich eine der wenigen Ausnahmen.
 
H

httpdigest

Ich denke mal, den Typ in welcher Form auch immer in den Namen eines Bezeichners zu kodieren, kommt aus einer Zeit, in der es keine vernünftigen IDEs gab, in der man sehr leicht durch diverseste Toolingunterstützung im Quellcode navigieren kann (ich denke, das wurde hier auch schon mal genannt) und in der man sich auch Quelltext auf Papier ausgedruckt hatte. Ich habe noch kein Projekt gesehen, in dem tatsächlich der Typ einer Variablen (wie auch immer) in den Bezeichner kodiert wurde.
 
Thema: 

Software Entwicklung

Passende Stellenanzeigen aus deiner Region:
Anzeige

Neue Themen

Anzeige

Anzeige
Oben