Was ist die Konvention für Worttrennzeichen in Java-Paketnamen?

370

Wie soll man Wörter in Paketnamen trennen? Welche der folgenden Aussagen sind richtig?

com.stackoverflow.my_package (unterstreichen)
com.stackoverflow.my-package (Bindestriche)
com.stackoverflow.MyPackage (CamelCase)

Was ist der allgemeine Standard?

java naming-conventions package

— Jigar
quelle

15

Ein anderes Beispiel, das noch nicht erwähnt wurde, verwendet einen Punkt:com.stackoverflow.my.package

— Brad Cupit

11

(2) ist kein legales Java. Unklar, warum Sie überhaupt danach fragen.

— Marquis von Lorne

Beachten Sie, dass dies alles nur dazu dient, die Eindeutigkeit sicherzustellen. Das einzige, was tatsächlich erzwungen wird, ist, sich aus dem Java-Raum herauszuhalten.

— Thorbjørn Ravn Andersen

248

Das offizielle Dokument der Namenskonventionen schreibt Folgendes vor:

Pakete

Das Präfix eines einzigartigen Paketname wird in allen-Klein ASCII - Buchstaben immer geschrieben und sollte einer der Top-Level - Domain - Namen, die derzeit sein com, edu, gov, mil, net, org, oder einer der englischen zwei Buchstaben bestehenden Codes zu identifizieren Länder nach ISO Standard 3166, 1981.

Nachfolgende Komponenten des Paketnamens variieren gemäß den internen Namenskonventionen einer Organisation. Solche Konventionen können festlegen, dass bestimmte Verzeichnisnamenskomponenten Abteilungs-, Abteilungs-, Projekt-, Maschinen- oder Anmeldenamen sind.

Beispiele

com.sun.eng

com.apple.quicktime.v2

edu.cmu.cs.bovik.cheese

Verweise

java.sun.com - Codekonventionen / Benennung

Beachten Sie, dass insbesondere alles, was dem Domänenpräfix der obersten Ebene folgt, im obigen Dokument nicht angegeben ist. Das JLS stimmt dem auch mit den folgenden Beispielen zu:

com.sun.sunsoft.DOE

gov.whitehouse.socks.mousefinder

com.JavaSoft.jag.Oak

org.npr.pledge.driver

uk.ac.city.rugby.game

Der folgende Auszug ist ebenfalls relevant:

In einigen Fällen ist der Internetdomänenname möglicherweise kein gültiger Paketname. Hier sind einige vorgeschlagene Konventionen für den Umgang mit diesen Situationen:

Wenn der Domainname einen Bindestrich oder ein anderes Sonderzeichen enthält, das in einem Bezeichner nicht zulässig ist, konvertieren Sie ihn in einen Unterstrich.

Wenn eine der resultierenden Paketnamenkomponenten Schlüsselwörter sind, fügen Sie ihnen einen Unterstrich hinzu.

Wenn eine der resultierenden Paketnamenskomponenten mit einer Ziffer oder einem anderen Zeichen beginnt, das nicht als Anfangszeichen eines Bezeichners zulässig ist, wird der Komponente ein Unterstrich vorangestellt.

Verweise

JLS 6.1-Paketnamen

— Polygenschmierstoffe
quelle

52

Kapitel 7.7 empfiehlt sogar die Verwendung des Unterstrichs in Paketnamen!

— Andreas Dolk

1

Aktualisierte Referenzen: docs.oracle.com/javase/specs/jls/se7/html/jls-6.html#jls-6.1 docs.oracle.com/javase/specs/jls/se7/html/jls-7.html# jls-7.1 (es gibt nicht mehr 6.8.1 und 7.7)

— Victor

6

Hier: oracle.com/technetwork/java/codeconventions-135099.html es sagt alles unten, aber hier docs.oracle.com/javase/specs/jls/se7/html/jls-6.html#jls-6.1 es sagt Daß die erste Komponente in Kleinbuchstaben geschrieben werden sollte, wurden auch Beispiele für die Worttrennung in Großbuchstaben entfernt. Auch hier: docs.oracle.com/javase/tutorial/java/package/namingpkgs.html steht Kleinbuchstaben. Es scheint also, dass derzeit von Großbuchstaben in Paketnamen abgeraten wird.

— Dhblah

27

In Kapitel 7.7 wird die Verwendung von Unterstrichen nicht empfohlen. Es wird empfohlen, spezielle / ungültige Symbole durch einen Unterstrich zu ersetzen, der weit davon entfernt ist, nur für die allgemeine Verwendung empfohlen zu werden.

— eduard.dudar

270

Alle drei sind nicht die Konventionen.

Verwenden Sie com.stackoverflow.mypackage.

Die Paketnamen folgen nicht der Konvention zur Benennung von Kamelhüllen oder Unterstrichen oder Bindestrichen .

Außerdem gibt Google Java Style Guide genau die gleiche (dh com.stackoverflow.mypackage) Konvention an:

5.2.1 Paketnamen

Paketnamen sind alle in Kleinbuchstaben geschrieben, wobei aufeinanderfolgende Wörter einfach miteinander verknüpft sind (keine Unterstriche). Zum Beispiel com.example.deepspace, nicht com.example.deepSpace oder com.example.deep_space.

- Google Java Style Guide: 5.2 Regeln nach Bezeichnertyp: 5.2.1 Paketnamen .

— Prahler
quelle

9

Ich stimme teilweise zu - sie sind nicht "falsch" gemäß den Java-Namenskonventionen, aber sie sollten meiner Meinung nach nicht verwendet werden. ( java.sun.com/docs/codeconv/html/CodeConventions.doc8.html )

— Andreas Dolk

@Andreas_D Der von Ihnen angegebene Link besagt, dass "das Präfix eines eindeutigen Paketnamens immer in Kleinbuchstaben ASCII geschrieben wird"

— Jose Gómez

1

@ JoseGómez "Die Präfix ". Imho schließt dies nicht alle anderen Wörter aus, die einen Paketnamen enthalten, von CamelCase oder snake_case

— Antek

21

Jeder kann den Unterstrich _ verwenden (es ist okay)

Niemand sollte Hypen benutzen - (seine schlechte Praxis)

Niemand sollte Großbuchstaben in Paketnamen verwenden (schlechte Praxis)

HINWEIS: Hier ist "Bad Practice" für technisch gedacht, dass Sie das verwenden dürfen, aber herkömmlicherweise ist es nicht gut zu schreiben.

Quelle: Benennen eines Pakets (docs.oracle)

— Himanshu Mori
quelle

47

Ja, die Verwendung eines Bindestrichs ist eine schlechte Praxis, da es sich um einen Fehler handelt. Und das Schreiben von Code, der nicht kompiliert wird, ist in der Tat eine schlechte Praxis.

— glglgl

Guter Link - hilft dabei, all dem einen Kontext zu geben, wenn Sie wissen, was die Quelle sagt. Ich bin auch an alle Kleinbuchstaben gewöhnt. Aber laut den Dokumenten scheint es einfach eine Frage der Wahl / des Stils zu sein. Ich habe dem spezifischen Beitrag , der nach dem Kamelfall für Paketnamen gefragt wurde, einen Kommentar hinzugefügt (was meiner Meinung nach kein Duplikat dieses Beitrags ist, übrigens - der nur nach der Konvention im Allgemeinen fragt) stackoverflow.com/questions/36755783/…

— Gene Bo

"Keine Großbuchstaben", obwohl ich zustimmen würde, dass alle Großbuchstaben oder etwas, das wie ein Klassenname aussieht, eine schlechte Idee ist, wird auch dieses Beispiel eliminiert. Zu sagen "es ist schlechte Praxis" ist der nicht überzeugendste, vage und bedeutungsloseste Grund, den ich mir vorstellen kann. Kann dies näher ausgeführt werden? (dh "schlechte Praxis" definieren)

— Manius

Sie sagen im Grunde immer noch "es ist schlecht", ohne zu begründen, warum es als schlecht angesehen werden sollte. Bricht es Werkzeuge? Verwirrung stiften? Ist es schwieriger zu lesen oder zu tippen? Für die gegebenen Beispiele können wir meiner Meinung nach viele von ihnen mit Ja beantworten. Aber ich kann ein absolutes Verbot von Großbuchstaben nicht verstehen . Ein Paketname LikeThis (wie ein Klassenname) ist offensichtlich verwirrend, aber likeThis ist für mich nicht verwirrend und scheint für einen Paketnamen mit zwei Wörtern wie bigdataSource (vs "bigdatasource") besser lesbar zu sein. Wenn es keinen Grund gibt, warum camelCase eine schlechte Idee für Pakete ist, von denen ich nichts weiß, scheint das in Ordnung zu sein.

— Manius

Es stellte sich heraus, dass ich Folgendes verpasst habe: oracle.com/technetwork/java/codeconventions-135099.html Alle Kleinbuchstaben sind Teil der Oracle-Konvention für Paketnamen. Ich denke immer noch, dass dies eine ziemlich beschissene Konvention ist, um Kamelfälle auszuschließen, die niedriger beginnen, für die (seltenen) Zeiten, in denen Sie einen Paketnamen mit zwei Wörtern verwenden müssen und es keinen Sinn macht, zwei Verzeichnisse zu erstellen. Aber na ja.

— Manius

18

Die offiziellen Namenskonventionen sind nicht so streng, sie "verbieten" nicht einmal die Notation von Kamelfällen außer dem Präfix ( comin Ihrem Beispiel).

Aber ich persönlich würde Großbuchstaben ~~und Silbentrennungen~~ vermeiden , gerade Zahlen. Ich würde wählen, com.stackoverflow.mypackagewie Bragboy es auch vorgeschlagen hat.

(Silbentrennungen '-' sind in Paketnamen nicht zulässig)

BEARBEITEN

Interessant - die Sprachspezifikation hat auch etwas über Namenskonventionen zu sagen.

In Kapitel 7.7 Eindeutige Paketnamen sehen wir Beispiele mit Paketnamen, die aus Großbuchstaben bestehen (daher wäre die CamelCase-Notation in Ordnung), und sie schlagen vor, die Hyphonierung durch einen Unterstrich ("mary-lou" -> "mary_lou") und das Präfix java zu ersetzen Schlüsselwörter mit einem Unterstrich ("com.example.enum" -> "com.example._enum")

Weitere Beispiele für Großbuchstaben in Paketnamen finden Sie in Kapitel 6.8.1 Paketnamen .

— Andreas Dolk
quelle

2

Wie Andreas bemerkt hat, gibt es keine Regeln für die Verwendung des oberen Gehäuses in Paketnamen. Ein besonderer Grund, dies zu vermeiden, ist, dass bei der plattformübergreifenden Entwicklung Probleme mit gemischten Paketnamen aufgetreten sind. Insbesondere wenn sich jemand entscheidet, den Fall eines Pakets umzubenennen oder zu ändern, verlassen Sie sich sowohl auf Ihr VCS als auch auf Ihre Entwicklungsumgebungen, um genau das Richtige mit dem Verzeichnisfall zu tun .

— Geschoren

2

Tatsächlich gibt es Regeln: "Das Präfix eines eindeutigen Paketnamens wird immer in Kleinbuchstaben geschrieben" ( oracle.com/technetwork/java/codeconventions-135099.html )

— Jose Gómez

4

Unterstriche sehen in Paketnamen hässlich aus. Für das, was es wert ist, verwende ich bei Namen, die aus drei oder mehr Wörtern bestehen, Initialen (zum Beispiel :) com.company.app.ingresoegresofijo (ingreso/egreso fijo) -> com.company.app.iefijound dokumentiere dann den Zweck des Pakets in package-info.java.

— jpangamarca
quelle

4

Dies ist möglicherweise nicht lesbar und schwierig, den Inhalt des Pakets zu verstehen, wenn man nur den Paketnamen betrachtet

— Vishal Akkalkote

1

Meinetwegen. Deshalb schlage ich vor, Dokumentation zu verwenden. Ich würde diesen Ansatz jederzeit verwenden, anstatt vollständige Wörter zu verketten (Apiratesheet - ist das 'API Rate Sheet' oder 'A Pirate Sheet'?)

— jpangamarca

1

Die Verkettung von Wörtern im Paketnamen ist etwas, was die meisten Entwickler nicht tun.

Sie können so etwas wie verwenden.

com.stackoverflow.mypackage

Siehe JLS-Namenserklärung

— CraUmm
quelle