एंड्रॉइड आईडी नामकरण सम्मेलन: अंडरस्कोर बनाम ऊंट मामले के साथ निचला मामला

Question

मैं वर्तमान में Android के लिए एक एप्लिकेशन प्रोग्रामिंग कर रहा हूं। अब मुझे जो पता चला वह यह है कि आप संसाधन वस्तुओं को नहीं रख सकते हैं, कह सकते हैं कि एक छवि, जो खींचने योग्य फ़ोल्डर में है और इसे "myTestImage.jpg" की तरह नाम दें। यह आपको एक कंपाइलर त्रुटि देगा क्योंकि ऊंट केस सिंटैक्स की अनुमति नहीं है, इसलिए आपको इसे "my_test_image.jpg" की तरह नाम बदलना होगा।

लेकिन क्या आप XML फ़ाइल में परिभाषित आईडी के बारे में। मान लें कि आपकी निम्नलिखित परिभाषा है

<TextView android:id="@+id/myTextViewFirstname"
              android:layout_width="wrap_content"
              android:layout_height="wrap_content"
              android:text="Firstname" />

यह एक वैध परिभाषा है, संकलन और मेरे एंड्रॉइड एमुलेटर पर ठीक काम करता है, हालांकि - जैसा कि आप देखते हैं - मैं ऊंट मामले सिंटैक्स में आईडी को निर्दिष्ट कर रहा हूं।

अब, एंड्रॉइड के नमूने हमेशा लोअर केस और अंडरस्कोर का उपयोग करते हैं। क्या यह आईडी के लिए अंडरस्कोर के साथ निचले मामले का उपयोग करने के लिए सिर्फ एक नामकरण सम्मेलन है या यह वास्तविक डिवाइस पर समस्याएं पैदा कर सकता है?

धन्यवाद

Answer 1

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

मैं धीरे-धीरे ऊंट-मामले पर अपना मन बदल रहा हूं, हालांकि, क्योंकि आप दो अलग-अलग नामकरण सम्मेलनों के साथ समाप्त होते हैं - उदाहरण के लिए:

// This must be undescored due to naming constrictions
setContentView(R.layout.my_long_layout_name);

// Now this looks a little out of place
findViewById(R.id.myLongSpecificId);

मैं भी, यहाँ के मानकों के बारे में सोचता हूँ। Google उनके उदाहरणों में असंगत है; कभी-कभी वे सभी लोअरकेस का उपयोग करते हैं, कभी-कभी वे अंडरस्कोर डालते हैं, और कभी-कभी वे ऊंट-केस का उपयोग करते हैं।

Comments

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

— जुरी

बस जिज्ञासा के लिए: क्या आपके पास एक लिंक है जहां Google असंगत है, जिसका अर्थ है कि उन्होंने आईडी के लिए ऊंट-केस संकेतन का उपयोग किया है?

— जूरी

भ्रमित बातें आगे करने के लिए, शैली नाम परियोजना टेम्पलेट्स में (जो शैलियों के लिए आईडी की तरह हैं) PascalCase, जैसे का उपयोग AppBaseThemeऔर AppTheme।

— एडवर्ड ब्रे

अंडरस्कोर विधि को आमतौर पर उन टीमों में बहुत कम पठनीय माना जाता है जिनमें मैं शामिल रहा हूं। ऊंट मामले में अनुमति नहीं दी जा रही संसाधन फाइलों के नामों की कुछ अजीब सीमा को जावा इंटरफेस के बाकी हिस्सों के लिए आपकी सोच को प्रदूषित नहीं करना चाहिए - कैमकोलेज दृढ़ता से घनीभूत और मुझे नहीं लगता कि कोई भी नामकरण सम्मेलनों में एक नई "_" शैली में मजबूर करने के लिए धन्यवाद देगा।

— रिची एचएच

@ रीचर्ड रिले मुझे दिलचस्प लगता है, क्योंकि अंडरस्कोर के साथ शब्द सीमाएं ठीक से परिभाषित होती हैं जबकि ऊंट के मामले में वे एक साथ स्क्वीट होते हैं इसलिए मेरे पास ऊंट-आवरण वाले की तुलना में अंडरस्कोर-अलग नामों को पार्स करने का एक आसान समय है।

— जेएबी

Answer 2

यदि आप android.R.id.*खेतों को देखते हैं, तो आप देखेंगे कि ये सभी ऊंट के मामले में हैं। इसलिए अगर android ids ऊंट-केस में लिखी जाती हैं, तो मुझे लगता है कि हमें इस सम्मेलन का अनुसरण करना होगा :)

Comments

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

— रिची एचएच

हां, वे ऊंट मामले में बनाए गए थे। लेकिन ये आईडी एंड्रॉइड एपीआई से ही हैं इसलिए अगर एपीआई के निर्माता ने ऊंट मामले का उपयोग किया है तो मुझे लगता है कि यह उनके सम्मेलन का पालन करने के लिए एक अच्छा तरीका है।

— किरिल अलेक्जेंड्रोव

वहाँ widget_frameफ़ील्ड [ developer.android.com/reference/android/R.id.html#widget_frame]android.R.id.* फ़ील्ड में भी है । इस क्षेत्र में Google अंडरस्कोर का उपयोग नहीं ऊँट-केस करता है इसलिए ऊँट-केस कन्वेंशन के बारे में आपका निष्कर्ष सही है कि आईडी कन्वेंशन के लिए चुनाव गलत हो सकता है

— अहम् हाम्डी

Answer 3

मुझे लगता है कि यह अच्छा है अगर हम सभी छोटे अक्षरों का उपयोग अंडरस्कोर के साथ करते हैं।

बस इसे देखो (डैनियल ने जो जवाब दिया था उसे जोड़कर)

  // Camel Case
    TextView tvUserName = (TextView) findViewById(R.id.tvUserName);

    // Small Caps and Underscores
    TextView tvUserName = (TextView) findViewById(R.id.tv_user_name);

अपने स्वयं के अनुभव में मैं xml में ऊंट मामले के सम्मेलन में थोड़ा भ्रमित हो जाता हूं क्योंकि जब आप इसे जावा से जोड़ते हैं जो ऊंट के मामले का भी उपयोग करता है (क्योंकि यह मानक है) यह एक डॉप्लेगैंगर जैसा दिखता है।

Comments

यह बहुत व्यक्तिपरक है और क्यू के रूप में आप क्यों स्ट्रिंग आईडी के रूप में इसी तरह namee संसाधन फ़ाइलों खिचड़ी भाषा का जवाब नहीं है।

— रिची एचएच

Answer 4

मुझे लगता है कि अगर हम xml फाइलों में id के लिए अंडरस्कोर कन्वेंशन और क्लास फील्ड्स के लिए कैमल केस कन्वेंशन का उपयोग करते हैं तो यह हर डेवलपर को xml आईडी और क्लास फील्ड के बीच अंतर करने के लिए बेहतर विजिबिलिटी देगा।

Answer 5

यदि आप कुछ गोगल्स ऐप के नमूनों को देखते हैं जैसे:

https://github.com/google/iosched

वे अंडरस्कोर का उपयोग करते हैं। तो .... शायद यह है कि हमें यह कैसे करना चाहिए?

Answer 6

android:id="@+id/frag_account_button"
frag_account_button = ((ListView)view.findViewById(R.id.frag_account_button));

android:id="@+id/fragAccountButton"
fragAccountButton = ((ListView)view.findViewById(R.id.fragAccountButton));

सबसे पहले, यह निर्धारित करने के लिए कोई निश्चित मानक नहीं है कि कौन सा अधिक उचित है लेकिन मेरे पास इसके बारे में अपना विचार है। मेरा विचार ऊँट-केस कन्वेंशन के साथ XML आईडी और जावा वैरिएबल को ठीक उसी नाम पर रखने के लिए उचित है।

1. एक्सएमएल और जावा पक्ष दोनों के लिए परियोजना की खोज करके चर तक पहुंचना आसान है।

2. butterKnife लाइब्रेरी परिभाषा

   @BindView (R.id.infoTextView) TextViewFont infoTextView;

इस तरह रखना अधिक उचित है।

Comments

कोटलिन का दृश्य बंधन मक्खन के समान होता है, इसलिए मैं स्नेक_केस को पूरी तरह से छोड़ रहा हूं।

— रिक मार्टिन्स

Answer 7

xml फ़ाइल नाम (जो कि ड्रा करने योग्य फ़ोल्डर में उपयोग किया जाता है) सभी निचले मामले को अंडरस्कोर वर्ण _ द्वारा अलग किया जाना चाहिए क्योंकि पूंजीकृत फ़ाइल नाम xml में समर्थित नहीं हैं।

Comments

यह फ़ाइल नामों के बारे में नहीं है, और इसके अलावा, कुछ लोग ऊंट आवरण के पहले अक्षर को कैपिटलाइज़ नहीं करना पसंद करते हैं।

— जेस्पर

यह एक अजीब अनिर्णायक मुद्दा IMO है। आप में कोई फर्क नहीं करने के लिए केस सेंसिटिविटी है, नहीं, लेकिन क्यों नहीं एक ही डायरेक्टरी में समान नाम रूट कंपोनेंट वाली रिसोर्स फाइल्स पर प्रतिबंध लगाया जाए।

— रिची एचएच

(Btw इसे आईएस नाम बनाम संसाधन आईडी के बारे में है: ओपी को फिर से देखें)

— रिची एचएच

Answer 8

यदि एंड्रॉइड का कंपाइलर वास्तव में वही कर रहा है जो आप कहते हैं कि ऊंट मामले को प्रतिबंधित करना (जो कि बल्कि अजीब लगता है) तो आपको स्थापित सम्मेलनों से चिपके रहना चाहिए।

अनाज के खिलाफ जाने से केवल अनावश्यक भ्रम पैदा होगा। जहाँ संभव हो सभी जगहों पर चीजों को लगातार रखें।

Comments

आप शायद गलत समझे कि मैं क्या कहना चाह रहा था। कंपाइलर शिकायत करेगा यदि आप संसाधनों को फाइल की तरह रखते हैं और लिखते हैं कि ऊंट मामले में। हालाँकि, जब आप XML लेआउट फ़ाइलों में आईडी निर्दिष्ट करते हैं तो दूसरा मामला है। वहां आपको ऊंट-केस आईडी नाम रखने की संभावना है और एमुलेटर ठीक काम करता है। अब जैसा कि मैंने उल्लेख किया है, Google नमूने सभी my_id_name के रूप में हैं, लेकिन ऊँट-केस आईडी के नाम के आसपास बहुत सारे अन्य नमूने हैं ...

— Juri