Gilt "_" als Java Keyword?

_ sind glaube ich als Präfixes verboten... Sieht ja auch bescheiden aus.
Nein, ein _ ist selbstverständlich erlaubt.

JLS 3.8 zeigt auf, wie ein Identifier aussehen darf:
The "Java letters" include uppercase and lowercase ASCII Latin letters A-Z (\u0041-\u005a), and a-z (\u0061-\u007a), and, for historical reasons, the ASCII dollar sign ($, or \u0024) and underscore (_, or \u005f). The dollar sign should be used only in mechanically generated source code or, rarely, to access pre-existing names on legacy systems. The underscore may be used in identifiers formed of two or more characters, but it cannot be used as a one-character identifier due to being a keyword.
Was ich jetzt weggekürzt habe: JavaLetter sind die Zeichen, mit denen ein Identifier starten muss. (Danach kommen die JavaLetterOrDigit)

Und das "bescheiden Aussehen" kann man durchaus auch anders sehen. So war dies in .Net durchaus nicht unüblich für private Variablen (Da gab es keine Vorgaben von Microsoft da die Vorgaben nur nach außen Sichtbares bestimmt hat). Und in dart ist das die Grundlage für die Sichtbarkeit (also da gibt es kein private keyword sondern eben nur den _ mit dem die Variable startet).
 
Dennoch schlechter Stil.
Kannst Du das mit irgendwelchen Gründen untermauern? Warum sollte eine Variable, die nur in der Klasse oder in dem Package sichtbar ist, eben nicht mit einem _ anfangen? Weil Du der Meinung bist, ist nicht sehr überzeugend. Das einzige Argument, das ich derzeit sehe: Es ist bei Java Entwicklern unüblich.

Aber Microsoft hat Dinge, die nach außen nicht sichtbar sind, schon aus gutem Grund eben nicht vorgegeben.

_ sollte nicht als erlaubter Präfix mitaufgeführt werden...
Warum? Spätestens hier wäre eine Begründung wichtig. Es entspricht der JLS. Daher MUSS es als erlaubt aufgeführt werden. Es explizit weg zu lassen oder zu behaupten, dass es nicht erlaubt ist, wäre schlicht falsch. Aber Java entwickelt sich ja weiter...
Was für Gründe gibt es aus Deiner Sicht dies zu ändern? Oder bei statischen Code-Analysen zumindest zu warnen. (Spätestens das wäre ja etwas einfaches. Tools und AddOns gibt es ja mehr wie genug, die in dem Bereich aktiv sind. Da wäre so eine Regel einfach umzusetzen)

Mich interessieren hier schlicht Gründe.

Von mir aus kann man ein Code Review annehmen. Und da hat dann jemand eine lokale Variable oder Instanzvariable mit einem _ gestartet. Wo sind aus Deiner Sicht die möglichen Probleme? Warum sollte so ein Pull Request abgewiesen werden?

Klar - ich selbst sehe es auch als unüblich an und benutze keine Variablennamen, die einen _ beinhalten (Also noch stärker. Nicht nur starten die nicht mit einem _ sondern sie beinhalten an keiner Stelle einen _!). Die kommen lediglich bei Konstanten innerhalb vor, da diese im Screaming Case geschrieben werden. Also schlicht das Argument: Unüblich. Das ist aber aus meiner Sicht in keiner Weise hinreichend, um Anderen dies zu untersagen.
 
(M)Ein Argument: ein _ wäre eher ein „technisches“ Detail (wie zB in Python), und hat daher in (den meisten) Namen nichts zu suchen. Genauso wie „I“ bei interfaces oder „p“ bei Parametern oder sonstige Prefixe, zB ungarische Notation.
 
Man könnte auch sagen: es entspricht nicht den Benennungskonventionen von Java 🙂
Das wird jetzt sehr spitzfindig: Gibt es die denn offiziell noch?

Ich finde da nur noch eine Version von 1999 die archiviert wurde (https://www.oracle.com/java/technologies/javase/codeconventions-namingconventions.html)

Daher mein etwas schwächeres "unüblich". Aber in dem Punkt sind wir uns ja einig. Und das wäre auch für jeden meine Empfehlung. Aber würde einer von euch darüber hinaus gehen? Das ist ein Punkt, den ich sehr unkritisch sehe.

Fiktiver Fall: Entwicklungsteam, das mit Dart und Java entwickelt schreibt seine eigenen Coding Guidelines incl. einem: private Instanzvariablen starten mit einem _.
Da die Firma zu viel Manpower für Entwickler hat, gibt es da auch gleich AddOns, die dies genau unterstützen. Also z.B. bei "int _wasAuchImmer" macht dan das AddOn direkt ein private hin oder so.
Eine pauschale Aussage "das ist schlechter Stil" würde mir da nicht über die Lippen kommen.

Oder wenn Dinge generiert werden - da könnte eine einfache Kennzeichnung ggf. auch Sinn machen. (Sowas hatte ich noch nicht, also bin ich nur am rumspinnen. Die Idee ist evtl. Quatsch. Sowas würde vermutlich ja in einer Klasse landen. Partial Classes kennt Java ja nicht im Gegensatz zu C#. Daher wird die Idee wohl ins Leere laufen ...)

In dem Ton nicht, nein. Aber benenne deine Variablen ruhig so, ich muss das ja nicht lesen zum Glück.
Was? Irgendwie frage ich mich, was Du da missverstehst. Das war eine einfache Nachfrage. Und es geht nicht darum, dass ich Variablen so benennen will. Es geht einfach darum, dass ich sowas nicht pauschal als "schlechten Stil" bezeichnen würde. Ich habe sogar so viel Fantasie, dass ich mir Szenen vorstellen kann, wo es zu "guten Stil" bzw. "erwünschtem Stil" werden könnte.

Und vor allem würde ich nie auf die Idee kommen, und verlangen, dass etwas, das die JLS explizit erlaubt, nicht mehr aufgeführt werden sollte. Spätestens so eine Aussage halte ich für extrem problematisch.

Aber Du musst gar nicht an der Diskussion teilnehmen. Verlangt niemand von Dir. Sowas haben wir hier durchaus öfters, dass Leute pauschale Aussagen treffen ohne Argumente zu haben. Ich sage nur "Anti-Pattern". Das ist kein Problem und auch etwas ganz natürliches. Gerade am Anfang hat man halt oft Regeln, die man befolgt, weil eine Autorität (Lehrer, Professor, Ausbilder) es so gesagt hat und man hat halt kein Verständnis, wieso etwas so gemacht werden soll. Also alles ok.
 
Schön, jetzt habe ich die Seite überflogen. Und an welcher Stelle stecht, dass eine Variable nicht mit einem _ anfangen darf? War zumindest beim Überfliegen auf dem Handy nicht zu finden.

Und es geht da auch nicht um Java. Daher wirkt das auch etwas fehl am Platz. Zumal ich ja darauf hingewiesen habe, dass dies sehr wohl explizite Erfordernisse sein können (Dart).

Und schon wieder pauschale Aussagen, dass so Code falsch sein würde. Aber du hast offensichtlich nicht verstanden, über was wir hier reden und was an Deiner Aussage kritisiert wurde.

Und genau so Auseinandersetzungen wollte ich ich mehr. Wieso da jemand eine Person angehen muss, werde ich nie verstehen. Das bringt doch absolut nichts, aber ok, du bist jetzt in dem 'Du hast mir widersprochen und nun bin ich böse auf Dich' Modus.

Das Schlimme ist: es juckt mich in den Fingern, da jetzt einfach etwas zu Sticheln. Kaum nimmt man mir wegen Wartungsarbeiten einen Teil der Entwicklungsumgebung, schon bin ich nicht genug ausgelastet. Und das soll bis Montag Abend eob. gehen .... Also ok: wollen wir die Person was angehen? ...
 
Das wird jetzt sehr spitzfindig: Gibt es die denn offiziell noch?
Naja, was heißt "offiziell"? Letztlich sind das natürlich alles nur Empfehlungen aber ich denke schon, dass die Konventionen immer noch eine Rolle spielen (und spielen sollten).

Was macht denn z. B. Lombok aus einem
Java:
@Getter
private int _age;
oder wie sieht es mit der JavaBean-Specification aus? Gibt es Tools, die auf einen lowerCamelCase vertrauen?
 
Ich weiß ja nicht, wieso man das überlesen muss:

Underscore, a Friend Indeed
Use _ and __ as identifiers.

aber das wird mir hier zu blöd.

"_" als Identifier ist in Java nicht erlaubt, das ist doch genau der Grund für den Thread? Und nicht erlaubt deshalb, um es als expliziten "nicht-identifier" zu nutzen...


@kneitzel bezog sich auch nirgendwo auf _ und __ als Identifier...
 
Naja, was heißt "offiziell"? Letztlich sind das natürlich alles nur Empfehlungen aber ich denke schon, dass die Konventionen immer noch eine Rolle spielen (und spielen sollten).
Da stimmen wir ja auch zu 100% überein und das war ja auch meine Aussage. Daher wäre das offiziell oder nicht nur eine Veränderung im Wording (aus meiner Sicht). Empfehlung ist es generell, denn das Wording war auch immer "should" und nicht "must".

Aber vielleicht versuche ich nur noch einmal den Kernpunkt zu formulieren:
Auslöser war ja einfach nur, dass das mit _ als "sieht bescheiden aus" beurteilt wurde und ich das ganz allgemein (nicht Java spezifisch) darauf hingewiesen habe, dass dies durchaus anders gesehen wird. (z.B. Dart). Damit wäre es eigentlich erledigt - Jemand anderes hat eine andere Sichtweise. Ist ok. Ist halt Geschmackssache und darüber kann man nicht streiten. Aber leider wurde es noch massiv verstärkt und die Frage ist:

Ist ein Verstoß etwas, das dann direkt zu schlechtem Code führt?

Im normalen Java Umfeld mit aktuellen Tools würde ich nach der Diskussion ganz klar sagen: Ja. (Vorher war ich da deutlich unsicherer.)

Aber die Frage ist ja, wie sich etwas weiter entwickelt. Tools verändern sich. Frameworks verändern sich. Wenn sich da also irgendwas durchsetzen sollte, dann unterstützen das mehr und mehr Tools. Ich habe halt viele Jahre Software-Entwicklung auf dem Buckel. Es galt mal ein klares Gebot, Typen mit anzugeben, also eine Variable "pszName" (pointer to String, zero-terminated) zu nennen statt nur "name". Ist doch eine krasse Veränderung über die Zeit gewesen.
Und heutzutage kennen wir viele Tools, die uns aktiv unterstützen. Generatoren wie Lombok aber auch aspekt orientierte Entwicklung. Derzeit wird da dann eher mit Annotations gearbeitet und das scheint mir auch das Naheliegende zu sein. Nur eben würde ich daher mit so Aussagen vorsichtig sein, die etwas einfach so verdammen.

Das "Es sollte so sein" bedeutet also nur "Es sollte so sein, so lange es keinen (guten) Grund gibt, es anders zu machen."

Meine Haltung kann ich dann auch etwas verallgemeinern. Schauen wir einmal auf die Pattern:
Das sind positive Orientierungen: Wenn Du so ein ähnliches Problem hast, dann könntest Du es so umsetzen.

Dann kommen aber regelmäßig Menschen (oder hier evtl. auch nur ein Mensch) und erwähnt "Anti-Pattern". Etwas darf dann nicht gemacht werden. Etwas ist schlecht. Regeln sind gut - gerade am Anfang. Es fehlt die Befähigung, etwas zu bewerten, daher gibt man eine Regel. Aber zu der Regel gehört dann immer die Begründung. Warum soll es so sein? Denn Regeln sind auch nur ein "should". Regeln werden regelmäßig gebrochen. Daher ist eine Bewertung wichtig zum abwiegen. ==> Ich bin also absolut kein Freund davon - zumindest so lange die Begründung fehlt.

Und das ist der Grund, wieso wir uns jetzt hier in der Diskussion befinden (Danke an der Stelle für eure Beiträge!)
Und das machte meine Beweggründe hoffentlich etwas deutlicher, falls dies bisher noch nicht deutlich genug war. Und erklärt auch das einfache Hinterfragen einer (aus meiner Sicht) aufgestellten Regel.
 

Zurück
Oben