जावा में इंटरफ़ेस नामकरण [बंद]

324

जैसा कि वर्तमान में खड़ा है, यह प्रश्न हमारे प्रश्नोत्तर प्रारूप के लिए एक अच्छा फिट नहीं है। हम तथ्यों, संदर्भों या विशेषज्ञता के आधार पर उत्तर दिए जाने की अपेक्षा करते हैं, लेकिन इस सवाल पर बहस, बहस, मतदान या विस्तारित चर्चा की संभावना होगी। यदि आपको लगता है कि इस प्रश्न को बेहतर बनाया जा सकता है और संभवतः फिर से खोला जा सकता है, तो मार्गदर्शन के लिए सहायता केंद्र पर जाएं ।

8 साल पहले बंद हुआ ।

अधिकांश OO भाषाएँ अपने इंटरफ़ेस नामों को एक पूँजी I के साथ जोड़ देती हैं, तो Java ऐसा क्यों नहीं करता है? इस अधिवेशन का पालन न करने का औचित्य क्या था?

प्रदर्शित करने के लिए कि मैं क्या मतलब है, अगर मैं एक यूजर इंटरफेस और एक उपयोगकर्ता कार्यान्वयन मैं जावा में दो विकल्प होता चाहते थे:

क्लास = यूजर, इंटरफ़ेस = यूजरइंटरफेस

क्लास = यूजरआईएमपीएल, इंटरफ़ेस = उपयोगकर्ता

जहां अधिकांश भाषाओं में:

वर्ग = उपयोगकर्ता, इंटरफ़ेस = IUser

अब, आप तर्क दे सकते हैं कि आप हमेशा उपयोगकर्ता के कार्यान्वयन के लिए एक सबसे वर्णनात्मक नाम चुन सकते हैं और समस्या दूर हो जाती है, लेकिन जावा चीजों के लिए एक पीओजेओ दृष्टिकोण को धक्का दे रहा है और अधिकांश आईओसी कंटेनर डायनामिकप्रोसेस का बड़े पैमाने पर उपयोग करते हैं। इन दोनों चीजों का एक साथ मतलब है कि आपके पास एकल POJO कार्यान्वयन के साथ बहुत सारे इंटरफेस होंगे।

इसलिए, मुझे लगता है कि मेरा प्रश्न नीचे उबलता है: "क्या यह व्यापक इंटरफ़ेस नामकरण सम्मेलन का पालन करने के लायक है, विशेष रूप से प्रकाश में जहां जावा फ्रेमवर्क शीर्षक लग रहे हैं?"

java interface naming-conventions

— एलन लालोंडे
स्रोत

61

"अधिकांश भाषाओं में कहाँ"? .Net के अलावा कौन सी भाषाएं हैं?

— wds

2

विभिन्न भाषा समुदायों में अलग-अलग नामकरण परंपराएं हैं, और यह एक लंबे, लंबे समय के लिए सच है। यह पता लगाना कि नामकरण परंपराओं की उत्पत्ति कैसे होती है, कभी-कभी अनिवार्य रूप से लोकगीत अनुसंधान होते हैं।

— डेविड थॉर्नले

4

एक्लिप्स एक महत्वपूर्ण आउटलुक है जो जावा को आईफू शैली के नामकरण के साथ उपयोग करता है। wiki.eclipse.org/Naming_Conventions

— डेविड लियोनार्ड

2

आप (जावा में अच्छी तरह से) Android SDK में इंटरफेस के नाम पर एक नज़र डालें, तो आप यह है कि वे एक अंतरफलक नाम के अंत पर शब्द इंटरफेस है, की तरह के सम्मेलन में प्रयोग किया जाता देखेंगे NetworkInterface, DialogInterfaceआदि

— sandalone

21

जब यह बहुत लोकप्रिय है और इतने सारे लोगों के लिए यह सवाल "बंद नहीं हो सकता है तो रचनात्मक कैसे हो सकता है"?

— inor

329

मैं इंटरफेस पर एक उपसर्ग का उपयोग नहीं करना पसंद करता हूं:

उपसर्ग पठनीयता को चोट पहुँचाता है।
क्लाइंट्स में इंटरफेस का उपयोग करना कार्यक्रम का सबसे अच्छा तरीका है, इसलिए इंटरफेस के नाम यथासंभव छोटे और सुखद होने चाहिए। कार्यान्वयन वर्गों को उनके उपयोग को हतोत्साहित करने के लिए कुरूप होना चाहिए।
जब एक अमूर्त वर्ग से एक अंतरफलक के लिए कोड बदलना उपसर्ग के साथ एक कोडन सम्मेलन मैं कक्षा के सभी घटनाओं का नाम बदलने का मतलब है --- अच्छा!

— starblue
स्रोत

12

पूर्णतया सहमत। यदि आप स्वत: पूर्णता का उपयोग करते हैं तो टाइप करने के लिए एक और कुंजी। फ़ाइलों की बहुत सारी I

— Kalecser

85

कोई भी सभ्य आईडी आसान तरीके से आपके द्वारा बताए गए तरीके से कोड को बदल देता है। इसके अलावा, जब एक अमूर्त वर्ग से एक इंटरफ़ेस में बदल रहा हूँ तो मुझे पूरा यकीन है कि आपके ग्राहकों को वैसे भी फिर से इकट्ठा करने की आवश्यकता होगी।

— एलन लालोंडे

63

सुपर देर यहाँ है, लेकिन: यह कोई फर्क नहीं पड़ता सब पर अगर एक IDE आसान कुछ का नाम बदलने में आता है। किसी प्रकार के उदाहरण का उपयोग करने वाले कोड को कभी भी ध्यान नहीं देना चाहिए कि क्या वह प्रकार एक इंटरफ़ेस या एक वर्ग है या क्या है। जैसे, प्रकार के नाम पर इस तरह के विवरण को उजागर करना समझ से बाहर है। प्रकार और अनुबंध यह उजागर करता है कि क्या मायने रखता है!

— कोलिनड

11

इसके अलावा, यदि आप IFoo के मार्ग पर जा रहे हैं, तो क्या इसे कार्यान्वयन के लिए CFoo नहीं होना चाहिए और निश्चित रूप से विफलता पर एक विधि EFoo को फेंक देगी।

— रॉबिन

57

"उपसर्ग पठनीयता को चोट पहुँचाता है" विशुद्ध रूप से व्यक्तिपरक है। जैसा कि ज्यादातर नामकरण परंपराएं हैं। यह अधिक मायने रखता है कि आपकी टीम समझौते पर बैठती है कि क्या करना है ताकि कोड आधार सुसंगत हो।

— dreadwail

121

क्या वास्तव में इसके बीच अंतर है:

class User implements IUser

तथा

class UserImpl implements User

अगर हम सभी के बारे में बात कर रहे हैं, तो सम्मेलनों का नामकरण किया जा रहा है?

व्यक्तिगत Iरूप से मैं इंटरफ़ेस से पहले पसंद नहीं करता हूं क्योंकि मैं इंटरफ़ेस को कोड करना चाहता हूं और मैं मानता हूं कि नामकरण सम्मेलन के संदर्भ में यह अधिक महत्वपूर्ण है। यदि आप इंटरफ़ेस कहते हैं, IUserतो उस वर्ग के प्रत्येक उपभोक्ता को इसका पता होना चाहिए IUser। अगर आप क्लास को कॉल करते हैं UserImplतो केवल क्लास और आपके DI कंटेनर को ही Implपार्ट के बारे में पता होता है और उपभोक्ताओं को सिर्फ यह पता होता है कि वे ए के साथ काम कर रहे हैंUser ।

तो फिर, बार मैं उपयोग करने के लिए मजबूर किया गया है Impl क्योंकि एक बेहतर नाम स्वयं मौजूद नहीं है और बीच में बहुत कम हैं क्योंकि कार्यान्वयन को नाम के अनुसार लागू किया जाता है क्योंकि यह वह जगह है जहां यह महत्वपूर्ण है, जैसे।

class DbBasedAccountDAO implements AccountDAO
class InMemoryAccountDAO implements AccountDAO

— tddmonkey
स्रोत

मुझे लगता है कि आप इसका DAO जानना चाहते हैं क्योंकि कक्षा खोलने की आवश्यकता के बिना सामान्य कार्यक्षमता का वर्णन करता है। अगर मैं एक परियोजना में वर्ग फ़ाइलों के माध्यम से देख रहा हूँ, तो यह सभी DAO को देखने के लिए सभी DAO को देखना आसान है

— पैट्रिक

6

DAO डेटाबेस एक्सेस के लिए एक जाना माना पैटर्न है, इसलिए नाम में पैटर्न होने से यह जानना आसान हो जाता है कि क्लास सिर्फ अपने नाम को देखकर क्या करती है। PS बेहतर होगा कि ऊंट संकेतन का सख्ती से पालन करें ("खातादेओ") जैसे कि mina.apache.org/changes-between-2x-and-1x.html

— Esko Luontola

4

@marker, यह एक इंटरफ़ेस इंगित करने के लिए I की तरह नहीं है। डीएओ आपको बताता है कि खाता डेटा तक पहुंचने के लिए क्लास या इंटरफ़ेस एक ऑब्जेक्ट है, जो ऑब्जेक्ट करता है। एक होने के बाद मैं आपको इसका एक इंटरफेस बताता हूं, जिसका वस्तु से कोई लेना-देना नहीं है, लेकिन भाषा का शब्दार्थ है

— tddmonkey

जैसा कि आप इसे प्रस्तुत करते हैं, इसका उपसर्ग बनाम प्रत्यय।

— आंद्रेई रैनिया

3

@Andrei: नहींं, यह शब्दार्थ ("DAO") बनाम एक भाषा विरूपण साक्ष्य की अनावश्यक सजावट ("I" जैसा कि इंटरफ़ेस में है; एक तथ्य, जो कोड में वर्णित है वैसे भी "इंटरफ़ेस IFoo ...")

— डिर्क

75

आमतौर पर जावा IUser सम्मेलन का उपयोग नहीं करने के कई कारण हो सकते हैं।

ऑब्जेक्ट-ओरिएंटेड दृष्टिकोण का एक हिस्सा यह है कि आपको यह जानना नहीं चाहिए कि क्लाइंट इंटरफ़ेस या कार्यान्वयन वर्ग का उपयोग कर रहा है या नहीं। तो, यहां तक कि सूची एक इंटरफ़ेस है और स्ट्रिंग एक वास्तविक वर्ग है, एक विधि दोनों को पारित किया जा सकता है - यह इंटरफेस को नेत्रहीन भेद करने के लिए कोई मतलब नहीं है।
सामान्य तौर पर, हम वास्तव में ग्राहक कोड में इंटरफेस का उपयोग करना पसंद करेंगे (उदाहरण के लिए, सूची के लिए ArrayList को प्राथमिकता दें)। इसलिए इसका मतलब यह नहीं है कि इंटरफेस को अपवाद के रूप में खड़ा किया जाए।
जावा नामकरण सम्मेलन हंगरी-शैली के उपसर्गों के वास्तविक अर्थों के साथ लंबे नामों को पसंद करता है। तो यह कोड जितना संभव हो उतना पठनीय होगा: एक सूची एक सूची का प्रतिनिधित्व करती है, और एक उपयोगकर्ता एक उपयोगकर्ता का प्रतिनिधित्व करता है - एक IUser नहीं।

— एवी
स्रोत

72

एक अन्य सम्मेलन भी है, जिसका उपयोग स्प्रिंग सहित कई खुले स्रोत परियोजनाओं द्वारा किया जाता है।

interface User {
}

class DefaultUser implements User {
}

class AnotherClassOfUser implements User {
}

मुझे व्यक्तिगत रूप से सरल कारण के लिए "I" उपसर्ग पसंद नहीं है जो कि इसका एक वैकल्पिक सम्मेलन है। इसलिए अगर मैं इसे अपनाता हूं तो IIOPConnection का मतलब IOPConnection का एक इंटरफेस है? क्या होगा यदि कक्षा में "I" उपसर्ग नहीं है, तो क्या मुझे इसका इंटरफ़ेस नहीं पता है..यहाँ उत्तर नहीं है, क्योंकि सम्मेलनों का हमेशा पालन नहीं किया जाता है, और उन्हें पुलिसिंग अधिक काम पैदा करेगी जो कि सम्मेलन खुद को बचाता है।

— एनजी।
स्रोत

मुझे यह पसंद है, क्योंकि यह आपको बाहरी निर्भरता के लिए इंटरफेस का उपयोग करने के तरीके में मदद करता है, बल्कि तब कक्षाओं को युग्मित करता है।

— मैट ब्रिग्स

47

जैसा कि एक अन्य पोस्टर में कहा गया है, यह आमतौर पर इंटरफेस को परिभाषित करने के लिए बेहतर है कि क्षमताओं को टाइप न करें। मैं "उपयोगकर्ता" की तरह कुछ "लागू" नहीं करना चाहूंगा और यही कारण है कि "इयूसर" अक्सर यहां वर्णित तरीके से वास्तव में आवश्यक नहीं है। मैं अक्सर कक्षाओं को संज्ञा और विशेषण के रूप में देखता हूं:

class Number implements Comparable{...}  
class MyThread implements Runnable{...}
class SessionData implements Serializable{....}

कभी-कभी एक विशेषण का कोई मतलब नहीं होता है, लेकिन मैं अभी भी मॉडल व्यवहार, कार्यों, क्षमताओं, गुणों आदि के लिए इंटरफेस का उपयोग कर रहा हूं, ... प्रकार नहीं।

इसके अलावा, यदि आप वास्तव में केवल एक उपयोगकर्ता बनाने जा रहे हैं और इसे उपयोगकर्ता कहते हैं तो IUser इंटरफ़ेस होने की भी क्या बात है? और अगर आपके पास कुछ अलग प्रकार के उपयोगकर्ता होने जा रहे हैं, जिन्हें एक सामान्य इंटरफ़ेस को लागू करने की आवश्यकता है, तो इंटरफ़ेस के "I" को लागू करने से आपको कार्यान्वयन के नाम चुनने में क्या मदद मिलती है?

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

— nairbv
स्रोत

मुझे लगता है कि आपके द्वारा "विशेषण के रूप में इंटरफेस" का समर्थन करने के लिए दिए गए उदाहरण तिरछे हैं, क्योंकि उन इंटरफेस को मिक्स-इन (या लक्षण) की तरह अधिक पसंद किया जाता है। इस प्रकार, विशेषण और संज्ञा दोनों के लिए इंटरफेस अच्छे हैं - लेकिन शायद indefinite transitive verbs 8 ^ P के लिए नहीं

— Stevel

इसे अंतिम वर्षों में बदला जा सकता है। दैवज्ञ। प्रकारों के लिए इंटरफेस की अनुमति देता है: [लिंक] docs.oracle.com/javase/tutorial/java/IandI/interfaceAsType.html

— karlihnos

38

बॉब ली ने एक बार एक प्रस्तुति में कहा था:

यदि आपके पास केवल एक कार्यान्वयन है, तो इंटरफ़ेस का बिंदु क्या है।

इसलिए, आप एक इंटरफ़ेस के बिना एक कार्यान्वयन के साथ शुरू करते हैं। बाद में आप तय करते हैं, ठीक है, यहाँ एक इंटरफ़ेस की आवश्यकता है, इसलिए आप अपनी कक्षा को एक इंटरफ़ेस में परिवर्तित करते हैं।

तब यह स्पष्ट हो जाता है: आपके मूल वर्ग को उपयोगकर्ता कहा जाता था। आपके इंटरफ़ेस को अब उपयोगकर्ता कहा जाता है। शायद आपके पास एक UserProdImpl और एक UserTestImpl है। यदि आपने अपने एप्लिकेशन को अच्छी तरह से डिज़ाइन किया है, तो हर वर्ग (जो कि इंस्टेंट यूजर को छोड़कर) अपरिवर्तित रहेगा और ध्यान नहीं देगा कि अचानक वे एक इंटरफ़ेस पास कर लेते हैं।

तो यह स्पष्ट हो जाता है -> इंटरफ़ेस उपयोगकर्ता कार्यान्वयन UserImpl।

— एंड्रियास पीटरसन
स्रोत

18

इंटरफेस का उपयोग करना प्रेरित विकास का परीक्षण करेगा। हमने डोमेन मॉडल और परीक्षण के साथ कई मुद्दों में भाग लिया है क्योंकि हमने तय किया है कि इंटरफेस का उपयोग न करें। मेरे एक मित्र ने एक बार उद्धृत किया था: "सब कुछ एक इंटरफ़ेस है, यह आपको लंबे समय में बचाएगा।"

— हुकंाक

4

मॉकिंग और आसान प्रॉक्सी सपोर्ट। मुझे यकीन है कि इंटरफेस प्रदान करने के लिए अन्य कारण भी हैं।

— MetroidFan2002

3

जैसा कि मैंने हाल ही में एक सहकर्मी से कहा, अब एक इंटरफ़ेस शुरू करने के लिए कुछ भी नहीं खर्च होता है, लेकिन बाद में आपको बहुत समय बचा सकता है।

— tddmonkey

2

यदि आपके पास निकट भविष्य में अन्य कार्यान्वयन हो सकते हैं, तो एक इंटरफ़ेस एक प्लस होगा।

— स्टेफ

3

मुझे यह पसंद नहीं है कि "मुझे भविष्य में एक और प्रत्यारोपण की आवश्यकता हो" तर्क। मुझे एक YAGNI दृष्टिकोण पसंद है: उन चीजों के लिए योजना न बनाएं जो अभी तक नहीं हुई हैं।

— डेविड लैवेंडर

24

C # में है

public class AdminForumUser : UserBase, IUser

जावा कहेगा

public class AdminForumUser extends User implements ForumUserInterface

इस वजह से, मुझे नहीं लगता कि इंटरफेस के लिए जावा में कन्वेंशन लगभग महत्वपूर्ण हैं, क्योंकि इनहेरिटेंस और इंटरफ़ेस कार्यान्वयन के बीच एक स्पष्ट अंतर है। मैं कहूंगा कि आप किसी भी नामकरण सम्मेलन का चयन करें, जब तक आप संगत हैं और लोगों को दिखाने के लिए कुछ का उपयोग करें कि ये इंटरफेस हैं। कुछ वर्षों में जावा नहीं किया गया, लेकिन सभी इंटरफेस सिर्फ अपनी निर्देशिका में होंगे, और यह सम्मेलन था। वास्तव में इसके साथ कोई समस्या नहीं थी।

— मैट ब्रिग्स
स्रोत

22

शायद मैं खराब जावा कोडर हूं, लेकिन मैं C # शैली पसंद करता हूं, इसका मतलब है कि सभी इंटरफेस 'I' उपसर्ग के साथ शुरू होते हैं :)

— davs

7

मुझे यकीन नहीं है कि आप और दूसरों को यह कहां से मिल रहा है। यह जावा पुस्तकालयों में स्पष्ट नहीं है ...

— चीफट्वो पेंसिल्स

6

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

उदाहरण के लिए, आपके मामले में, मैं केवल यह देखने की अपेक्षा करूंगा कि IUserक्या एकमात्र उपयोगकर्ता आपके पास कभी होने का इरादा रखता है User। यदि आप विभिन्न प्रकार के उपयोगकर्ताओं - NoviceUser, ExpertUserआदि की योजना बनाते हैं - तो मैं एक Userइंटरफ़ेस देखने की उम्मीद करूँगा (और, शायद, एक AbstractUserवर्ग जो कुछ सामान्य कार्यक्षमता को लागू करता है, जैसे get/setName())।

मैं भी इंटरफेस है कि क्षमताओं को परिभाषित उम्मीद करेंगे - Comparable, Iterable, आदि - ऐसा नाम दिया जाना चाहिए, और की तरह नहीं IComparableया IIterable।

— डेविड कोएले
स्रोत

यदि एकमात्र उपयोगकर्ता जिसे आप कभी भी उपयोग करने का इरादा रखते हैं, तो उपयोगकर्ता इंटरफ़ेस के बजाय उपयोगकर्ता का उपयोग क्यों नहीं करता है?

— कैरिगन

3

कुछ क्लाइंट / सर्वर आर्किटेक्चर में, क्लाइंट पक्ष को हेवीवेट सर्वर कार्यान्वयन की आवश्यकता के बिना इंटरफेस को जानना होगा।

— डेविड कोएले

5

अच्छे OO सिद्धांतों के बाद, आपका कोड (जहाँ तक व्यावहारिक / संभव है) ठोस वर्गों के बजाय अमूर्तताओं पर निर्भर होना चाहिए। उदाहरण के लिए, इस तरह की विधि लिखना आम तौर पर बेहतर होता है:

public void doSomething(Collection someStuff) {
    ...
}

उसके बाद यह:

public void doSomething(Vector someStuff) {
    ...
}

यदि आप इस विचार का पालन करते हैं, तो मैं कहता हूं कि यदि आप "IUser", "UserInterface", या अन्य विविधताओं के बजाय "उपयोगकर्ता" और "BankAccount" (उदाहरण के लिए) जैसे इंटरफेस नाम देते हैं तो आपका कोड अधिक पठनीय होगा।

कोड के एकमात्र बिट्स जिन्हें वास्तविक कंक्रीट कक्षाओं के बारे में ध्यान देना चाहिए, वे स्थान हैं जहां कंक्रीट कक्षाओं का निर्माण किया जाता है। इंटरफेस का उपयोग करके बाकी सब कुछ लिखा जाना चाहिए।

यदि आप ऐसा करते हैं, तो "UserImpl" जैसे "बदसूरत" ठोस वर्ग नामों को बाकी कोड से सुरक्षित रूप से छिपाया जाना चाहिए, जो "अच्छा" इंटरफ़ेस नामों का उपयोग करके आसानी से आगे बढ़ सकते हैं।

— KarstenF
स्रोत

लेकिन अपने कार्यक्रम में प्रत्येक वर्ग के लिए एक मिलान इंटरफ़ेस बनाने में क्यों परेशान होते हैं जब आपको केवल एक या दो चीजों के लिए इंटरफेस की आवश्यकता होती है?

— लेजेंड लय

3

= v = "I" उपसर्ग का उपयोग विकेट फ्रेमवर्क में भी किया जाता है, जहां मुझे इसकी जल्दी आदत हो गई है। सामान्य तौर पर, मैं किसी भी सम्मलेन का स्वागत करता हूँ जो बोझिल जावा क्लासनाम को छोटा करता है। यह एक परेशानी है, हालांकि, सब कुछ निर्देशिकाओं और जावदोक में "आई" के तहत वर्णानुक्रम में है।

विकेट कोडिंग अभ्यास स्विंग के समान है, जिसमें कई नियंत्रण / विजेट उदाहरणों को इनलाइन विधि घोषणाओं के साथ गुमनाम आंतरिक वर्गों के रूप में निर्मित किया जाता है। वार्षिक रूप से, यह स्विंग से 180 ° भिन्न होता है कि स्विंगिंग कार्यान्वयन कक्षाओं के लिए एक उपसर्ग ("जे") का उपयोग करता है।

"इम्प्ल" प्रत्यय एक आम तौर पर संक्षिप्त नाम है और अच्छी तरह से अंतर्राष्ट्रीयकरण नहीं करता है। यदि केवल हम कम से कम "छोटा सा भूत" के साथ गए थे तो यह कम्यूटर (और छोटा) होगा। "Impl" का उपयोग IOC, विशेष रूप से स्प्रिंग के लिए किया जाता है, इसलिए हम इसके लिए अभी से अटके हुए हैं। यह एक कोडबेस के तीन अलग-अलग हिस्सों में 3 अलग-अलग सम्मेलनों के बाद थोड़ा सा सिज़ो हो जाता है।

— जैम डायर
स्रोत

0

क्या यह किसी भी वास्तविक अर्थ में व्यापक नामकरण सम्मेलन है? मैं C ++ की ओर अधिक हूं, और वास्तव में जावा और वंशजों पर नहीं। कितने भाषा समुदाय I सम्मेलन का उपयोग करते हैं?

यदि आपके पास यहां भाषा-स्वतंत्र दुकान मानक नामकरण सम्मेलन है, तो इसका उपयोग करें। यदि नहीं, तो भाषा के नामकरण सम्मेलन के साथ जाएं।

— डेविड थॉर्नले
स्रोत