मैं अपने कोड और डेटाबेस फ़ील्ड नाम आदि में camelCase का उपयोग करता हूं, लेकिन अंत में Id फ़ील्ड के साथ, यह हमेशा पढ़ने के लिए कठिन होता है। उदाहरण के लिए, itemId, teacherId, unitId इत्यादि। इन मामलों में मैं बेहतर पठनीयता के लिए सम्मेलन तोड़ने और itemID, teacherID, or unitID लिखने पर विचार करता हूं।आईडी, आईडी, या आईडी?
आप क्या करते हैं और इस मुद्दे से निपटने का सामान्य, सर्वोत्तम अभ्यास क्या है?
मैं जो करता हूं वह करता हूं। आम तौर पर, आपका सर्वोत्तम अभ्यास कुछ अमूर्त मानक के साथ पठनीयता बनाम अनुपालन के पक्ष में गलती करना है।
बस सुसंगत रहें।
मैं कैमेलकेस का भी उपयोग करता हूं और यदि आईडी आईडी के साथ समाप्त होता है तो मैं इसका भी उपयोग करता हूं।
आईडी
यह व्यक्तिपरक प्रश्न के लिए मेरा व्यक्तिपरक उत्तर है।
मैंने इसे सीडब्ल्यू के रूप में चिह्नित किया है।
आईडी के साथ समस्या यह है कि मैं गैर पूंजी टी के समान दिखता हूं। तो यूनिट आईडी –
पढ़ने के लिए काफी संदिग्ध है इस फ़ॉन्ट में यह समान है। एक मोनोस्पेस्ड फ़ॉन्ट का उपयोग करते समय (जिसे मैं हर जगह उपयोग करने का प्रयास करता हूं जहां मैं कोड करता हूं) यह नहीं करता है। –
या लोअरकेस एल। मोनोस्पेस्ड फ़ॉन्ट्स में भी, समस्याएं हो सकती हैं। –
मैं आईडी का उपयोग करना पसंद करता हूं और हमारी कंपनी में मानक आईडी पर भी आईडी है। मुझे नहीं लगता कि आईडी का उपयोग करने में कोई समस्या है यदि आपको इसे पढ़ने में आसान लगता है। कंपाइलर परवाह नहीं है :) मैं अपने स्कीमा आईडी कॉलम में एक ही सम्मेलन का उपयोग करता हूं।
मुझे लगता है कि पठनीयता अत्यंत महत्वपूर्ण है, और इसे अपने सम्मेलन को ओवरराइड करना चाहिए यदि इसे पढ़ने के लिए इतना आसान बनाना है। मुझे लगता है कि यदि आप इसे आसानी से नहीं पढ़ सकते हैं (जितना हम प्रोग्रामर सम्मेलन और प्रोटोकॉल तोड़ने से नफरत करते हैं) तो विपक्ष आपकी बंदूकें/सम्मेलन में चिपकने के लिए पेशेवरों से अधिक है।
आईडी, पहचानकर्ता के लिए आईडी। माइक्रोसॉफ्ट के सुझाए गए नामकरण सम्मेलन इंगित करते हैं कि यह अनुशंसित अभ्यास है और कोड विश्लेषण के साथ संकलन उस का समर्थन करेगा। यदि आप आई और डी के साथ क्रमशः दो शब्दों के लिए खड़े थे तो आप आईडी का उपयोग करेंगे और आपको वास्तव में लोअरकेस अक्षरों से शुरू होने वाले नामों का उपयोग नहीं करना चाहिए बल्कि पैरामीटर में।
आईडी "पहचान की पहचान" के लिए खड़ा है। किसी भी चीज़ के लिए एक संक्षिप्त शब्द बनाना संभव है। ;) –
सहमत हुए। प्रत्येक गैर-तुच्छ परियोजना को कोड विश्लेषण (FxCop) का उपयोग करना चाहिए जो "आईडी" के बजाय "आईडी" का सुझाव देगा। –
मुझे नहीं लगता कि ओपी ने माइक्रोसॉफ्ट का उल्लेख किया है। –
इससे कोई फर्क नहीं पड़ता, जब तक आप अपने प्रोग्राम पर लगातार रहते हैं।
कहा जा रहा है, मैं "आईडी" के साथ जाऊंगा।
मैं दोनों बयानों से सहमत हूं, सुसंगत रहें और 'आईडी' के साथ जाएं क्योंकि ... 404 –
यहां मैं जो करता हूं उसका एक नमूना है।
id
userId
getUserId
कुंजी लगातार है।
सीडब्ल्यू जोड़ा गया जब मैंने देखा कि कितने अन्य थे। –
सभी अच्छे बच्चे इसे कर रहे हैं! –
@Daniel वे निश्चित हैं :) –
मैं अपने सभी टेबल नामों में अंडरस्कोर का उपयोग करता हूं, इसलिए user_id। यहां तक कि यदि आईडी स्टैंडअलोन है, तो यह सब लोअरकेस है।
विभिन्न भाषाओं में अलग-अलग दिशानिर्देश हैं। .NET के लिए आप Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries पढ़ सकते हैं। जावा के लिए आप Code Conventions for the Java Programming Language पढ़ सकते हैं।
आईडी संक्षिप्त नाम नहीं है, इसलिए मुझे यह "आईडी" है। यूआई एक संक्षिप्त शब्द है, और शब्दकोष - छोटे, वैसे भी - पूंजीकृत प्राप्त करें: "यूआई।"
यहां सबसे अच्छा जवाब; आश्चर्यचकित कोई भी इसे ऊपर उठाया नहीं है। +1 :) – bryan
एफडब्ल्यूआईडब्ल्यू, कुछ सुझाव देंगे (.NET Framework Design दिशानिर्देशों के अनुसार) कि केवल दो अक्षर शब्दकोष पूरी तरह से पूंजीकृत होते हैं, अब सभी शब्दकोष सामान्य शब्दों के रूप में पूंजीकृत होते हैं। उदा।, डेफेरियो और एक्सएमएल रीडर। यह एक उचित और पठनीय दृष्टिकोण seams। लेकिन आईडी अभी भी आईडी है। :) –
भी FWIW आईडी शब्दकोश के अनुसार आधिकारिक संक्षेप है। मैं सुझाव दूंगा कि यदि आप आईडी करते हैं तो आपको यू और यूआरएल भी करना चाहिए। – slifty
मैं वास्तव में "आईडी" पसंद करता हूं। लेकिन, जैसा कि सभी कहते हैं, स्थिरता सबसे महत्वपूर्ण बात है।
स्टीव
मैं "आईडी" का उपयोग करता हूं, यह स्थिरता तोड़ता है लेकिन यह अधिक पठनीय है। – awaisj
हां, मुझे यह और अधिक पठनीय लगता है, यही कारण है कि मैं इसका उपयोग करता हूं। लेकिन यदि आप हमेशा "आईडी" (उदा। "UserID", "commentID") का उपयोग करते हैं, तो यह स्थिरता क्यों तोड़ता है? –
उसका मतलब यह हो सकता है कि शेष कोड camalCase है और आईडी एकमात्र चीज है जो –
Machine SUIF में, माइक स्मिथ और ग्लेन होलोवे सख्ती से मामले परंपरा है कि बड़े अक्षर एक नया शब्द के निशान को लागू। तो हालांकि सीपीएस एक संक्षिप्त शब्द है, यह transformToCps है और transformToCPS नहीं है। मैंने पाया है कि लंबे समय तक, उनकी विधि Quick C-- में हमने जो किया है उससे बेहतर काम करता है, जहां हमने आम तौर पर आईडी और सीपीएस जैसे मामलों के लिए सभी कैप्स किए हैं।
मैं यहां मतदान करने जा रहा हूं, लेकिन मुझे परवाह नहीं है!
यह स्पष्ट रूप से id है। गहरे से विचार!
FxCop/कोड विश्लेषण खराब संक्षेप के रूप में आईडी को ध्वजांकित करेगा, इसलिए यदि आप किसी नियम को अक्षम करने से बचना चाहते हैं, तो आप उस कारण से आईडी का पालन और उपयोग कर सकते हैं। लेकिन फिर, यह वास्तव में कोई फर्क नहीं पड़ता, जब तक आप लगातार होते हैं, जैसा कि दूसरों द्वारा इंगित किया गया है।
जब भी आप अपने स्वयं के कार्यक्रमों में लगातार बने रहें, तब तक आप जो भी सहज महसूस कर रहे हों। (यदि आप किसी टीम में काम करते हैं, तो आपको टीम के नियम का पालन करना चाहिए या कुछ सेट अप करना चाहिए)।
एक बिंदु जिसका उल्लेख नहीं किया गया है वह एक अच्छा फ़ॉन्ट प्राप्त करने का महत्व है। यही कारण है कि अपने कार्यक्रम पठनीयता के लिए चमत्कार कर देगा और यह हो सकता है कि आपके सम्मेलन समस्या आंशिक रूप से एक फ़ॉन्ट समस्या है:
आप आसानी से ld से ईद भेद नहीं कर सकते हैं(Id and ld), आप फ़ॉन्ट और शायद फ़ॉन्ट बदलने के लिए करना चाहिए आकार भी व्यक्तिगत रूप से, मुझे कंसोलस पसंद है।
मैं अन्य उत्तरों से सहमत हूं कि सबसे महत्वपूर्ण बात सुसंगत होना है।
मैं इसे जोड़ दूंगा, अगर आपके विशेष कोडबेस के लिए स्थापित मानक नहीं है, तो आपको अपनी भाषा या प्लेटफ़ॉर्म द्वारा निर्धारित सम्मेलनों का पालन करना चाहिए। जावा में, संक्षिप्त और अन्य बड़े अक्षरों में लिखा शब्द पहचानकर्ता के लिए uncapitalized हैं:
id
url
getId()
setUrlParameters()
ऑब्जेक्टिव-सी में, यह विपरीत है। आप एक लोअरकेस "id" या "Url" चर हो सकता है, लेकिन आप भी इस तरह के रूप में श्रेणियां होती हैं:
setURLParameters:
सी में पूंजीकृत स्थिरांक बहुत बदसूरत लगती है। PHP ने इनमें से कुछ को भी विरासत में मिला है। –
यह है:
NSURL
NSURLRequest
तो मैं की तरह एक विधि नाम का चयन करेंगे उच्चारण "आंख डी", "आईडी, अहंकार और superego के रूप में आईडी" नहीं, तो आईडी, आईडी नहीं। यह मेरा वोट है, किसी भी तरह। तथ्य यह है कि यह एक संक्षिप्त नाम के बजाय संक्षेप है, जिस तरह से इसका उच्चारण किया गया है, अप्रासंगिक है। यह उच्चारण किया गया है कि यह एक संक्षिप्त शब्द था, इसलिए इसे इस तरह से टाइप किया जा सकता है। ओह, और ऊंट केस कंप्यूटिंग के इतिहास में सबसे बुरा विचार है। :)
"आईडी" संदिग्ध है। क्या यह मानव मानसिकता के "अहंकार"/"सुपररेगो" मॉडल का हिस्सा है? शायद नहीं: आप शायद "पहचान" या "पहचान" या "पहचानकर्ता" जैसे शब्द को संक्षिप्त करने की कोशिश कर रहे हैं।
आपके निर्णय का निर्णय करके अस्पष्टता (और आवरण प्रश्न) से छुटकारा पाएं और फिर संक्षिप्त न करें।
डेटाबेस कॉलम और ऑब्जेक्ट गुणों में आईडी।पैरामीटर में आईडी:
this.ID == id
सीडब्ल्यू सपना केवल कुछ ही सेकंड तक चलता है। – OscarRyz
c'est la vie, आदि इत्यादि ;-) – Shog9