जावा पैकेज नामों में शब्द विभाजक के लिए कौन सा सम्मेलन है?


370

पैकेज के नामों में एक अलग शब्द कैसे होना चाहिए? निम्नलिखित में से कौन सा सही हैं?

  1. com.stackoverflow.my_package (अंडरस्कोर)
  2. com.stackoverflow.my-package (हाइफ़न)
  3. com.stackoverflow.MyPackage (टेढ़े मेढ़े संयुक्त शब्द)

सामान्य मानक क्या है?


15
एक अन्य उदाहरण जो अभी तक उल्लेख नहीं किया गया है वह एक अवधि का उपयोग कर रहा है:com.stackoverflow.my.package
ब्रैड कपिट

11
(2) कानूनी जावा नहीं है। अस्पष्ट क्यों आप भी इसके बारे में पूछ रहे हैं।
लोर्न

ध्यान दें कि यह सब सिर्फ विशिष्टता सुनिश्चित करने के लिए है। केवल एक चीज जो वास्तव में लागू की जाती है वह है जावा से बाहर रहना। * अंतरिक्ष।
थोरबजोरन रावन एंडरसन

जवाबों:


248

यहां बताया गया है कि आधिकारिक नामकरण सम्मेलनों के दस्तावेज क्या हैं:

संकुल

एक अनूठा पैकेज नाम का उपसर्ग हमेशा सभी लोअरकेस ASCII अक्षरों में लिखा है और शीर्ष स्तर के डोमेन नामों में से एक हो सकता है, वर्तमान में com, edu, gov, mil, net, org, या अंग्रेजी दो अक्षर का कोड देशों की पहचान करने में से एक आईएसओ में विनिर्दिष्ट मानक 3166, 1981।

पैकेज नाम के बाद के घटक एक संगठन के अपने आंतरिक नामकरण सम्मेलनों के अनुसार भिन्न होते हैं। इस तरह के सम्मेलनों में निर्दिष्ट किया जा सकता है कि कुछ निर्देशिका नाम घटक विभाजन, विभाग, परियोजना, मशीन या लॉगिन नाम हो सकते हैं।

उदाहरण

  • com.sun.eng
  • com.apple.quicktime.v2
  • edu.cmu.cs.bovik.cheese

संदर्भ


ध्यान दें कि विशेष रूप से, शीर्ष-स्तरीय डोमेन उपसर्ग के बाद कुछ भी उपरोक्त दस्तावेज़ द्वारा निर्दिष्ट नहीं है। जेएलएस निम्नलिखित उदाहरण देकर भी इससे सहमत हैं:

  • com.sun.sunsoft.DOE
  • gov.whitehouse.socks.mousefinder
  • com.JavaSoft.jag.Oak
  • org.npr.pledge.driver
  • uk.ac.city.rugby.game

निम्नलिखित अंश भी प्रासंगिक है:

कुछ मामलों में, इंटरनेट डोमेन नाम एक मान्य पैकेज नाम नहीं हो सकता है। इन स्थितियों से निपटने के लिए कुछ सुझाए गए सम्मेलन हैं:

  • यदि डोमेन नाम में एक हाइफ़न, या कोई अन्य विशेष वर्ण पहचानकर्ता में अनुमत नहीं है, तो इसे अंडरस्कोर में परिवर्तित करें।
  • यदि परिणामी पैकेज नाम घटकों में से कोई भी कीवर्ड है तो उन्हें अंडरस्कोर करें।
  • यदि परिणामी पैकेज नाम घटकों में से कोई भी एक अंक के साथ शुरू होता है, या किसी भी अन्य चरित्र को जो कि एक पहचानकर्ता के प्रारंभिक चरित्र के रूप में अनुमति नहीं है, तो घटक के लिए एक अंडरस्कोर होता है।

संदर्भ


52
अध्याय 7.7 पैकेज के नामों में अंडरस्कोर का उपयोग करने की भी सिफारिश करता है!
एंड्रियास डॉक

1
अद्यतित संदर्भ: 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 (कोई और अधिक 6.8.1 और 7.7)
विक्टर

6
यहाँ: oracle.com/technetwork/java/codeconventions-135099.html यह सब-लोअर कहता है, लेकिन यहाँ docs.oracle.com/javase/specs/jls/se7/html/jls-6s#jls-6.1 इसे कहते हैं पहला घटक निचले मामले में होना चाहिए, साथ ही उन्होंने ऊपरी केस शब्द पृथक्करण के उदाहरण हटा दिए। यहाँ भी: docs.oracle.com/javase/tutorial/java/package/namingpkgs.html इसे सभी लोअर केस कहते हैं। इसलिए ऐसा लगता है कि पैकेज नामों में ऊपरी मामला वर्तमान में हतोत्साहित किया गया है।
ढबला

27
अध्याय 7.7 अंडरस्कोर का उपयोग करने की अनुशंसा नहीं करता है, यह अंडरस्कोर के साथ विशेष / अमान्य प्रतीकों को बदलने की सिफारिश करता है जो सामान्य उपयोग के लिए सिर्फ सिफारिश करने से काफी दूर है।
eduard.dudar

270

तीनों ही कन्वेंशन नहीं हैं।

का उपयोग करें com.stackoverflow.mypackage

पैकेज के नाम ऊंट आवरण या अंडरस्कोर या हाइफ़न पैकेज नामकरण सम्मेलन का पालन नहीं करते हैं ।

इसके अलावा, Google जावा स्टाइल गाइड बिल्कुल उसी (यानी com.stackoverflow.mypackage) सम्मेलन को निर्दिष्ट करता है :

5.2.1 पैकेज के नाम

पैकेज के नाम सभी छोटे हैं, लगातार शब्दों के साथ बस एक साथ (कोई अंडरस्कोर नहीं)। उदाहरण के लिए, com.example.deepspace, नहीं com.example.deepSpace या com.example.deep_space

- Google जावा स्टाइल गाइड: 5.2 पहचानकर्ता प्रकार के नियम: 5.2.1 पैकेज नाम


9
मैं आंशिक रूप से सहमत हूं - जावा नामकरण सम्मेलनों के अनुसार वे 'गलत' नहीं हैं, लेकिन उनका उपयोग मेरी राय में नहीं किया जाना चाहिए। ( java.sun.com/docs/codeconv/html/CodeConventions.doc8.html )
एंड्रियास

@Andreas_D आपके द्वारा प्रदत्त लिंक बताता है कि "एक अनूठे पैकेज के नाम का उपसर्ग हमेशा सभी-निचले ASCII अक्षरों में लिखा जाता है"
जोस गोमेज़

1
@ जोसगोमेज़ " उपसर्ग "। तो imho यह अन्य सभी शब्दों को बाहर नहीं करता है जिसमें CamelCase या साँप_केस से एक पैकेज का नाम शामिल है
Antek

21

कोई भी अंडरस्कोर _ (इसके ठीक) का उपयोग कर सकता है

किसी को भी हाइपेन का उपयोग नहीं करना चाहिए - (इसका बुरा अभ्यास)

किसी को पैकेज के नाम के अंदर बड़े अक्षरों का उपयोग नहीं करना चाहिए (बुरा अभ्यास)

नोट: यहाँ "बुरा अभ्यास" तकनीकी रूप से आपके लिए उपयोग करने की अनुमति है, लेकिन पारंपरिक रूप से लिखने के लिए यह अच्छा व्यवहार नहीं है।

स्रोत: एक पैकेज का नामकरण (docs.oracle)


47
हां, एक हाइफ़न का उपयोग करना बुरा व्यवहार है, क्योंकि यह एक त्रुटि है। और कोड लिखना जो संकलन नहीं करता है, वास्तव में बुरा अभ्यास है।
17'17

अच्छा लिंक - यह सब कुछ संदर्भ देने में मदद करता है जब आप जानते हैं कि स्रोत क्या कहता है। मैं सभी निचले केस कन्वेंशन के लिए भी उपयोग किया जाता हूं। लेकिन डॉक्स के अनुसार, ऐसा लगता है कि यह केवल पसंद / शैली का मामला है। मैंने पैकेज नामों के लिए ऊंट मामले के बारे में पूछे गए विशिष्ट पद के लिए एक टिप्पणी जोड़ी है (जो मुझे नहीं लगता कि इस पोस्ट का एक डुप्लिकेट है, btw - जो सामान्य रूप से सम्मेलन के बारे में पूछता है) stackoverflow.com/questions/36755783/…
जीन बो

"कोई कैपिटल लेटर नहीं", हालांकि मैं इस बात से सहमत होता हूं कि क्लासनेम जैसा दिखने वाला सभी कैप या कुछ भी एक बुरा विचार है, यह भी इस एक्सप्लिमेंट को खत्म कर देता है। यह कहना कि "यह बुरा व्यवहार है" सबसे असंबद्ध, अस्पष्ट और व्यर्थ कारण है जिसके बारे में मैं सोच सकता हूं। क्या इसे विस्तृत किया जा सकता है? (यानी 'खराब प्रैक्टिस' को परिभाषित करें)
मैनिअस

आप अभी भी मूल रूप से कह रहे हैं कि "यह बुरा है" बिना औचित्य दिए कि इसे बुरा क्यों माना जाना चाहिए। क्या यह टूलींग को तोड़ता है? भ्रम पैदा करें? क्या पढ़ना मुश्किल है या टाइप करना? दिए गए उदाहरणों से मुझे लगता है कि हम उनमें से कई के लिए हां में जवाब दे सकते हैं। लेकिन मैं बड़े अक्षरों पर पूर्ण प्रतिबंध नहीं लगा सकता। एक पैकेज का नाम LikeThis (एक वर्ग नाम की तरह) स्पष्ट रूप से भ्रमित करने वाला है, लेकिन इस तरह यह मेरे लिए भ्रमित नहीं है और दो शब्द पैकेज नाम जैसे bigdataSource (बनाम "bigdatasource") के लिए अधिक पठनीय लगता है। जब तक कोई कारण नहीं है कि CamelCase संकुल के लिए एक बुरा विचार है जिससे मैं अनजान हूँ, यह ठीक लगता है।
मानस

यह पता चला है कि मैं इससे चूक गया: oracle.com/technetwork/java/codeconventions-135099.html ऑरेकल लोअरकेस Oracle के पैकेज नाम सम्मेलन का हिस्सा है। मुझे अभी भी लगता है कि ऊंट के मामले को खत्म करने के लिए एक बल्कि भद्दा सम्मेलन है, जो उन (दुर्लभ) समय के लिए कम शुरू होता है, जब आपको दो शब्द पैकेज नाम का उपयोग करने की आवश्यकता होती है और यह दो निर्देशिकाओं को बनाने के लिए समझ में नहीं आता है। लेकिन ओह हां।
मानस

18

आधिकारिक नामकरण परंपराएं इतनी सख्त नहीं हैं, वे उपसर्ग ( comआपके उदाहरण में) को छोड़कर ऊंट मामले की संज्ञा को 'मना' नहीं करते हैं ।

लेकिन मैं व्यक्तिगत रूप से ऊपरी मामलों के पत्रों और हाइफ़नेशन , यहां तक ​​कि संख्याओं से बचता हूं । मैं com.stackoverflow.mypackageभी Bragboy का सुझाव दिया पसंद करेंगे।

(hyphenations '-' पैकेज नामों में कानूनी नहीं हैं)

संपादित करें

दिलचस्प है - भाषा विनिर्देशन के नामकरण सम्मेलनों के बारे में भी कुछ कहना है।

में अध्याय 7.7 अनोखा पैकेज नाम हम चाहते हैं कि (ताकि केमलकेस अंकन ठीक हो जाएगा) अपर केस अक्षरों से मिलकर पैकेज के नाम के साथ उदाहरण देख सकते हैं और वे एक अंडरस्कोर ( "मरियम-लो" -> "mary_lou") द्वारा hyphonation को बदलने के लिए सुझाव देते हैं और उपसर्ग जावा अंडरस्कोर वाले कीवर्ड ("com.example.enum" -> "com.example._enum")

पैकेज नामों में ऊपरी केस पत्रों के कुछ और उदाहरण अध्याय 6.8.1 पैकेज नामों में पाए जा सकते हैं ।


2
जैसा कि एंड्रियास ने नोट किया है, पैकेज नामों में ऊपरी आवरण का उपयोग करने के बारे में कोई नियम नहीं है । इससे बचने का एक विशेष कारण यह है कि मैंने क्रॉस प्लेटफॉर्म डेवलपमेंट करते समय लोगों को मिश्रित केस पैकेज नामों के साथ समस्याओं में भागते देखा है। खास तौर पर जब कोई नाम बदलने या एक पैकेज के मामले को बदलने के लिए फैसला करता है, तो आप दोनों अपने VCS और विकास के वातावरण में निर्भर हैं, ऐसा करने के लिए वास्तव में निर्देशिका मामले से सही बात।
छीना हुआ

2
वास्तव में, नियम हैं: "एक अनूठे पैकेज नाम का उपसर्ग हमेशा सभी- निचले अक्षरों में लिखा जाता है ASCII पत्र" ( oracle.com/technetwork/java/codeconventions-135099.html )
जोस गोमेया

4

अंडरस्कोर पैकेज नामों में बदसूरत दिखते हैं। क्या मूल्य के लिए, तीन या अधिक शब्दों के यौगिकों के मामले में मैं इनिशियल का उपयोग करता हूं (उदाहरण के लिए:) com.company.app.ingresoegresofijo (ingreso/egreso fijo) -> com.company.app.iefijoऔर फिर पैकेज के उद्देश्य को दस्तावेज में package-info.java


4
यह केवल पैकेज के नाम को देखकर पैकेज की सामग्री को समझने के लिए पठनीय और मुश्किल नहीं हो सकता है
विशाल अक्कलकोट

1
काफी उचित। इसलिए मैं प्रलेखन का उपयोग करने का सुझाव देता हूं। मैं पूर्ण दृष्टिकोण के बजाय किसी भी समय इस दृष्टिकोण का उपयोग करूँगा (एपिलेटशीट - यह है कि 'एपीआई रेट शीट' या 'ए पाइरेट शीट'?)
jpangamarca

1

पैकेज के नाम में शब्दों का समास कुछ ऐसा है जो अधिकांश डेवलपर्स नहीं करते हैं।

आप कुछ का उपयोग कर सकते हैं।

com.stackoverflow.mypackage

जेएलएस नाम घोषणा को देखें

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.