नामकरण परंपराएँ: ऊंटकैसे बनाम अंडरस्कोर_केस? इसके बारे में आपके क्या विचार हैं? [बन्द है]

Question

मैं लगभग 2 साल से अंडरस्कोर_केस का उपयोग कर रहा हूं और मैंने हाल ही में नई नौकरी की वजह से कैमलकेस में स्विच किया है (लगभग 2 महीने के लिए बाद में एक का उपयोग कर रहा हूं और मुझे अभी भी लगता है कि अंडरस्कोर_केस बड़ी परियोजनाओं के लिए बेहतर अनुकूल है जहां प्रोग्रामर शामिल हैं, मुख्य रूप से क्योंकि कोड को पढ़ना आसान है)।

अब काम पर हर कोई ऊंट का उपयोग करता है क्योंकि (इसलिए वे कहते हैं) कोड अधिक सुरुचिपूर्ण दिखता है।

आप CamelCase या अंडरस्कोर_केस के बारे में क्या विचार रखते हैं

ps कृपया मेरी खराब अंग्रेजी बहाना

संपादित करें

कुछ अपडेट पहले:

• उपयोग किया गया प्लेटफ़ॉर्म PHP है (लेकिन मैं सख्त PHP प्लेटफ़ॉर्म संबंधित उत्तरों की उम्मीद नहीं कर रहा हूं, कोई भी अपने विचार साझा कर सकता है, जिस पर उपयोग करना सबसे अच्छा होगा, यही कारण है कि मैं यहां पहली बार आया हूं)

• मैं टीम में हमेशा की तरह ऊंट का उपयोग करता हूं (जैसा कि आप में से अधिकांश पुन: दावा करते हैं)

• हम Zend फ्रेमवर्क का उपयोग करते हैं जो कैमलकेस की सिफारिश भी करता है

कुछ उदाहरण (PHP से संबंधित):

• कोडराइटर फ्रेमवर्क अंडरस्कोर_केस की सिफारिश करता है, और ईमानदारी से कोड को पढ़ना आसान है।

• ZF कैमलकेस को पुनः प्राप्त करता है और मैं केवल एक ही ऐसा व्यक्ति नहीं हूं जो सोचता है कि ZF कोड का अनुसरण करना कठिन है।

तो मेरा प्रश्न पुनः होगा:

चलो एक मामला लेते हैं जहां आपके पास मंच फू है जो किसी भी नामकरण सम्मेलनों की सिफारिश नहीं करता है और यह टीम के नेता को चुनने के लिए है। आप उस टीम लीडर हैं, आप ऊंट को क्यों चुनेंगे या अंडरस्कोर_केस क्यों?

पी एस अब तक शीघ्र उत्तर के लिए सभी को धन्यवाद

Comments

"ईमानदारी से कोड को पढ़ना आसान है" राय या तथ्य?

— जद इसहाक

IThinkTheyAreBothAboutTheSame but_i_think_mixing_them_is_pretty_bad।

— डायटबुद्ध

@ डिट्टू बुद्ध: मैंने अभी 'IT_inkTheyAreBothAboutTheSame' की तुलना में 'but_i_think_mixing_them_is_pretty_bad' बहुत तेजी से पढ़ा। मुझे पूरा यकीन है कि वैज्ञानिक रूप से सिद्ध किया जा सकता है। :)

— स्टीवन ज्यूरिस

@ जॉन आइजैक: मैं रिपोर्ट करने के लिए दुखी हूं (एक गुप्त प्रस्तावक के रूप में), कि एक अध्ययन ने निष्कर्ष निकाला है कि "ऊंट आवरण प्रशिक्षण की परवाह किए बिना सभी विषयों में उच्च सटीकता की ओर जाता है" ।

— स्टीवन ज्यूरिस

IWonderWhetherReadingEnglishWrittenInOneStyleVersusAnotherMakesMuchDifference। InTheEnd, IFindThatNeitherIsVeryGoodAtBeingEasyToRead। It_screws_horribly_with_line_length_and_makes_even_the_simplest_thing_complicated। I_wonder_whether_there_would_be_language_support_in_the_future_for_quoted_variable_names। "यह मेरी राय में बहुत अधिक समझ में आता है या तो ऊंट कैससे या अंडरस्कोर_सेपर्स"।

— क्रिस्टोफर महान

Answer 1

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

लेकिन जहां एक विकल्प है, मैं ऊंट मामले में एक साधारण कारण के लिए पसंद करता हूं: मुझे वह शैली पढ़ने में आसान लगती है। यहाँ एक उदाहरण है: जो आपको अधिक पठनीय लगता है? इस:

aRatherLongSymbolName

या यह:

a_rather_long_symbol_name

मुझे अंडरस्कोर संस्करण पढ़ने में बहुत आसान लगता है। मेरे मस्तिष्क और अधिक आसानी से अंडरस्कोर अनदेखा कर सकते हैं की तुलना में यह ऊंट मामले में लोअरकेस / अपरकेस सीमाओं का पता लगाने सकता है, खासकर जहां सीमाओं ग्लिफ़ कि विपरीत मामले के अन्य ग्लिफ़ जैसे ही लगते हैं या अंकों के (के बीच हैं I/l, O/0, t/I, आदि)। उदाहरण के लिए, यह बूलियन वैरिएबल एक मान को दर्शाता है कि उचित नियोजन अनुमति के साथ इग्लू बनाया गया है या नहीं (निस्संदेह हम सभी के लिए एक सामान्य उपयोग मामला):

isIllicitIgloo

मुझे यह संस्करण पढ़ने में बहुत आसान लगता है:

is_illicit_igloo

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

Comments

अंडरस्कोर के साथ एक मुद्दा: प्रयोज्य। अधिकांश (यूरोपीय) कीबोर्ड के लिए, अंडरस्कोर साइन टाइप करने के लिए SHIFT कुंजी को दबाए रखना पड़ता है। आपको ऊंट के लिए भी ऐसा करने की आवश्यकता है, लेकिन मैं आराम से पिंकी के साथ SHIFT पकड़ सकता हूं और कोई भी पत्र टाइप कर सकता हूं - लेकिन चूंकि अंडरस्कोर कुंजी SHIFT कुंजी के ठीक बगल में है, इसलिए एक ही समय में दोनों को दबाया जाना बहुत अजीब है और इसमें बाधा उत्पन्न होती है टाइपिंग का प्रवाह।

— LearnCocos2D

पहले एक के लिए, मुझे वास्तव में ऊंट पढ़ने में आसानी हुई - हालांकि बाद स्पष्ट रूप से अलग है।

— फोजी 12

यह वास्तव में आप क्या करने के लिए इस्तेमाल कर रहे हैं पर निर्भर करता है। मुझे कैमलकेस आसान लगता है, और इसके अलावा, वे बराबर अंडरस्कोर नामों से छोटे हैं।

— जूनस पुलकका

मुझे अंडरस्कोर टाइपिंग से नफरत है ।

— एप्सिलॉनवेक्टर

"प्रयोज्य" बिंदु इसके लिए अप्रासंगिक है। कोड आमतौर पर एक व्यक्ति द्वारा केवल एक बार लिखा जाता है, लेकिन कुछ संपादन और संभावित जोड़ी प्रोग्रामिंग के लिए 1-10 बार लेखांकन के क्रम में कहते हैं। लेकिन कोड आमतौर पर एक या संभावित कई लोगों द्वारा दर्जनों / सैकड़ों / हजारों बार पढ़ा जाता है। इस प्रकार कोड को पढना आसान है, कई परिमाण लिखना आसान होने से अधिक महत्वपूर्ण है।

— २१:१३

Answer 2

मुझे लगता है कि आपको अपने मंच द्वारा अपनाई गई नामकरण परंपरा का उपयोग करना चाहिए। अंडरस्कोर_केस सी # कोड में अजीब लगेगा, रूबी में ऊंट के रूप में =)

Comments

संगति एक कुंजी है। चाहे आप स्थानीय सम्मेलन से सहमत हों या न हों, आप सुसंगत होकर अपना खुद का समय आसान (और बाकी सबका) बनाएंगे। (जब तक कि स्थानीय सम्मेलन स्वयं विसंगति नहीं है।) इसके अलावा, पठनीयता ज्यादातर एक गलत तर्क है: पर्याप्त कोड पढ़ें जो आपको पता चलेगा कि जब तक आप यह तय नहीं करते हैं तब तक बहुत कम अंतर होता है।

— रिचर्ड

पूरी तरह से सहमत। मुझे लगता है कि कस्टम लोगों के बजाय मंच सम्मेलन का उपयोग करना बेहतर है, क्योंकि उदाहरण के लिए टीम में नए लोग इसके साथ अधिक सहज महसूस करेंगे।

— एलेक्सी अनफ्रीयेव

लेकिन हम में से जो दो सम्मेलनों के साथ दो प्लेटफार्मों में काम करते हैं, जहां कुछ पसंद करते हैं और कुछ दूसरे को पसंद करते हैं!

— माइकल के

यदि प्लेटफ़ॉर्म में 2 कन्वेंशन हैं, तो मैं सभी टीम के सदस्यों को उस कन्वेंशन के लिए वोट करने के लिए कहूंगा जो वे =) के साथ सहज हैं।

— एलेक्सी एनुफ्रियेव

Answer 3

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

Comments

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

— पॉलीनेका

Answer 4

एक जवाब के आधार पर जॉन इसहाक का जवाब:

"ईमानदारी से कोड को पढ़ना आसान है" राय या तथ्य?

मैंने कुछ शोध करने का फैसला किया, और यह शोधपत्र पाया । विज्ञान विषय पर क्या कहना है?

1. ऊंट आवरण में अंडरस्कोर की तुलना में शुद्धता की एक बड़ी संभावना है । (अंतर 51.5% अधिक है)
2. औसतन, ऊंट मामले में 0.42 सेकंड लंबा समय लगा , जो अब 13.5% अधिक है।
3. प्रशिक्षण का कोई सांख्यिकीय महत्वपूर्ण प्रभाव नहीं है कि शैली शुद्धता को कैसे प्रभावित करती है।
4. उन लोगों के साथ और अधिक प्रशिक्षण तेज थे ऊंट मामले शैली में पहचानकर्ता पर।
5. एक शैली में प्रशिक्षण, अन्य शैलियों के लिए खोज समय को नकारात्मक रूप से प्रभावित करता है ।

में मेरी ब्लॉग पोस्ट इस विषय पर मैं वैज्ञानिक कागज समीक्षा करते हैं और निम्नलिखित निष्कर्ष बनाते हैं।

केवल ऊंट मामले की सुस्ती (2) प्रोग्रामिंग के लिए वास्तव में प्रासंगिक है, अन्य बिंदुओं को आधुनिक आईडीई के कारण अप्रासंगिक के रूप में खारिज कर दिया गया है और अध्ययन में ऊंट उपयोगकर्ताओं के बहुमत हैं। चर्चा (मतदान के साथ) ब्लॉग पोस्ट पर पाई जा सकती है।

मैं उत्सुक हूं कि यह लेख कैसे लोगों की राय बदल सकता है। :)

Comments

बेशक, आप अंडरस्कोर के लिए आपकी प्राथमिकता के कारण अन्य सभी बिंदुओं को खारिज कर देते हैं और अन्य बिंदु आपके मामले में मदद नहीं करते हैं ...

— चार्ल्स बॉयंग

@Charles: हां और नहीं, IMHO मैं अच्छे तर्क देता हूं कि वे क्यों खारिज करने योग्य हैं, और उनमें से कुछ को पेपर द्वारा ही समस्याग्रस्त के रूप में चर्चा की जाती है। एक अनुवर्ती कागज इस कागज की कुछ समस्याओं की जांच करता है , और परिणाम समर्थक अंडरस्कोर होते हैं।

— स्टीवन ज्यूरिस

Answer 5

होशियार लोग कॉपी करें

प्रोग्रामिंग भाषाओं के मामले में, भाषा के डेवलपर की शैली की प्रतिलिपि बनाएँ।

उदाहरण के लिए I कोड C ठीक उसी प्रकार है जैसा K & R में किया जाता है।

फिर जब कोई भी उबाऊ कोडिंग शैली की बातचीत शुरू करने की कोशिश करता है, तो मैं उन्हें बता सकता हूं कि "डेनिस रिटेक के साथ लाओ और मुझे बताएं कि वह क्या कहता है।"

Comments

मूल हमेशा सबसे अच्छा नहीं होता है। सी पर के एंड आर सुसमाचार की किताब में कई बुरी प्रथाएं हैं। इससे पहले कि यह एक लौ युद्ध शुरू हो ... कुछ MISRA सिफारिशों को पढ़ें।

— जल्‍दी से जल्‍दी से

जब कोई GUI-IDEs नहीं था तब K & R लिखा गया था। ज्यादातर काम 80x25 वर्ण टर्मिनलों पर किया गया था, इसलिए स्क्रीन स्पेस एक प्रीमियम पर था, जिससे if (...) {एक लाइन बच गई! इन दिनों, अधिक स्क्रीन स्पेस है - क्या कश्मीर और आर अलग-अलग होंगे अगर आज हाय-रेस जीयूआई आईडीई और मल्टीपल मॉनिटर सेट अप के साथ लिखा जाए?

— स्काईज डेस

हाँ, लेकिन जब कोई कहता है कि वे K & R की तरह C कोड करते हैं, तो उन्हें पुराने स्कूल जाने के लिए सहारा मिलता है।

— क्रिस्टोफर महान

@quickly_now, कि डेनिस रिची के साथ लाओ और मुझे बताएं कि वह क्या कहता है!

— मार्क हैरिसन

मैं एमएस से बहुत सारे फॉर्मेटिंग को अपनाता हूं: _internalToClassOnly, accessByGetter, PublicVariable।

— 22

Answer 6

सामान्य तौर पर, मैं कैमलकेस पसंद करता हूं। हालाँकि, ऐसा इसलिए है क्योंकि मेरे करियर के अधिकांश, मैं उन भाषाओं और परिवेशों में काम कर रहा हूँ जहाँ स्टाइल गाइड सामान्य रूप से कैमलकेस की सलाह देते हैं। (जावा, ईसीएमएस्क्रिप्ट, सी ++)। आप एक PHP व्यक्ति होने के नाते, विपरीत वरीयता होने की संभावना है।

उस ने कहा, जब आप तीनऑर्डफॉरमिक्स से परे जाते हैं, या यदि आप आद्याक्षर जैसे xmlForExample का उपयोग करते हैं, तो यह इतना पठनीय होना बंद हो जाता है।

यही कारण है कि emacs हमें चश्मा-मोड देता है।

Comments

मुझे चश्मा-मोड की खोज करने के लिए +1! मैंने अभी इसे एक कोड फ़ाइल पर परीक्षण किया है जो कैमलकेस का उपयोग करता है, और देखा कि यह तुरंत कैसे बेहतर दिखने लगा (असेंबली में लेबल के भार के साथ विधानसभा)।

— गौथियर

ठीक है, चश्मा-मोड क्या है?

— मार्सी

gnu.org/software/emacs/manual/html_node/emacs/Glasses.html

— पॉल बुचर

Answer 7

टेढ़े मेढ़े संयुक्त शब्द

यह उन कुछ स्थानों में से एक है जहां मैं हमेशा पठनीयता पर 'टाइप-क्षमता' चुनूंगा। CamelCase बस टाइप करना आसान है, और मेरी उंगलियों के लिए अच्छे होने के नाते मेरे लिए थोड़ी सी पठनीयता हासिल की है।

यह मानते हुए कि परियोजना मौजूदा कोडबेस पर एक अलग मानक के साथ नहीं बनती है।

Comments

मैं इससे सहमत नहीं हूं, आप केवल एक बार कोड लिखते हैं, लेकिन आपको इसे कई बार पढ़ना होगा

— रोमन पीकर

Answer 8

यह एक दिलचस्प सवाल है, मैंने इस पर कई बार सोचा है। लेकिन कोई निश्चित जवाब नहीं है, मुझे लगता है।

"सांस्कृतिक" सम्मेलनों के बाद यह एक अच्छा विकल्प है। इस मामले में "सांस्कृतिक" का अर्थ है टीम / कंपनी में स्थापित सम्मेलनों और वे मूल रूप से भाषा / मंच सम्मेलनों को भी साथ लेकर जाते हैं। यह दूसरों को आपके कोड को आसानी से पढ़ने / उपयोग करने में मदद करता है और आपको अपने कोड को समझने के लिए अतिरिक्त प्रयासों और समय की आवश्यकता नहीं होती है।

कभी-कभी स्वीकृत अधिसूचनाओं को तोड़ना दिलचस्प होता है। मेरी छोटी परियोजनाओं में से एक (पायथन पर) मैंने underscored_namesउपयोगिता कार्यों / "संरक्षित" विधियों और methodNamesविधियों के लिए जावा-शैली का उपयोग किया। मेरी टीम इससे खुश थी :)

Answer 9

प्रोग्रामिंग भाषा पर निर्भर करता है।

मैं हंगेरियन संकेतन का उपयोग करने या न करने के मामले में उसी मामले का उपयोग करने पर विचार करता हूं:

• पायथन: अंडरस्कोर_केस, नो हंगेरियन नोटेशन
• C ++: camelCase, हंगेरियन नोटेशन

Comments

@Kevin Cantu: असल नाम जावास्क्रिप्ट बल्कि CamelCase से PascalCase में है ...

— Guffa

@ गुफ़ा: छुआ!

— केविन कैंटू

@ केविन कैंटू: जावास्क्रिप्ट पर: XMLHttpRequest<- मैं एक जुनून के साथ इस नाम से नफरत करता हूं।

— थानातोस

काल्पनिक ऋतुएंटीन्यूक्रेडरमंड। एक्सश (XMLHttpRequest)

— केविन कैंटू

@ लायनेल: वास्तव में हंगेरियन अंकन का उपयोग C ++ में लगभग कभी नहीं किया गया है, क्योंकि C ++ पहले से ही आपके प्रकारों की जांच करता है। यह किसी भी चीज़ की तुलना में ऐतिहासिक कलाकृतियों से अधिक है।

— सिलिको

Answer 10

दोनों!

मैं CakePHP में बहुत विकास करता हूं, और मैं CamelCaseया तो $underscored_varsनिम्न फैशन में ( या CakePHP परियोजनाओं के बाहर भी) का उपयोग करता हूं :

1. फ़ाइल नाम - /lowercased_underscored.phpविशिष्ट, लेकिन ध्यान देने योग्य है।
2. कक्षाएं - class CamelCase extends ParentObject। ध्यान दें कि, उपयोग करते समय CamelCase, प्रारंभिक चरित्र लोअरकेस नहीं है। मुझे वास्तव में अजीब camelCaseलग रहा है ।
3. चर -$are_variables_underscored === TRUE;
4. चर जो उदाहरण प्रस्तुत करते हैं -$CamelCase = new CamelCase();
5. सरणी कुंजी -$collection['underscored_keys'];
6. स्थिरांक - मुझे लगता है कि हर कोई सहमत हो सकता है कि स्थिरांक होना चाहिए ALL_CAPS_AND_UNDERSCORED।
7. तरीके -$CamelCase->foo_method_underscored();
8. स्थैतिक तरीके -CamelCase::just_like_regular_methods();

Comments

आप के साथ सहमत होने के लिए है, पहले चरित्र कम मामले मुझे पागल हो ड्राइव! मैं एक जुनून के साथ ऊंट से नफरत करता हूं।

— HLGEM

जावा में जहाँ आमतौर पर नाम ऊँट होते हैं, वर्ग के नाम वास्तव में कैपिटल अक्षर से शुरू होते हैं। यह उन्हें विधि नामों से अलग करना है।

— जेम्स पी।

Answer 11

मैं व्यक्तिगत रूप से पसंद करता underscore_caseहूं क्योंकि मुझे यह अधिक पठनीय लगता है, लेकिन अन्य उत्तरदाताओं के साथ सहमत हूं जो बताते हैं कि मौजूदा कोडबेस के साथ स्थिरता अधिक महत्वपूर्ण है।

हालांकि, मेरे पास उन लोगों के लिए एक प्रतिरूप है जो कहते हैं कि "अपनी भाषा और इसके पुस्तकालयों के सम्मेलन का पालन करें"।

अतीत में हमने विंडोज का उपयोग करके C कोड लिखा था underscore_case, और PascalCaseWin32 फ़ंक्शन कहा जाता है:

if (one_of_our_conditions_is_true())
{
    call_one_of_our_functions();
    CallSystemFunction();
}

हमारे फ़ंक्शन नामों और Microsoft के फ़ंक्शन नामों के बीच दृश्य अंतर बाधा के बजाय मदद था, क्योंकि यह स्पष्ट रूप से दिखाया गया था जब कोड "सिस्टम लैंड" में जा रहा था।

इसके अलावा, मैं अपने संपादक के सिंटैक्स हाइलाइटिंग नियमों को अलग-अलग रंगों में प्रदर्शित करने में सक्षम था, जिसने कोड के अपरिचित वर्गों (या यहां तक ​​कि अपने) को समझने की कोशिश करते समय आगे दृश्य सुराग दिए।

Answer 12

मैं वास्तव में डायलन के सामान्य-सामान्य-डैश-जैसा-वे-से-टाइप-टू-एंड-ईज़ी-टू-ईज़ी-टू-रीड है।

पसंद

result-code := write-buffer(file-stream, some-string)

लेकिन मुझे लगता है कि यह भाषा काफी अस्पष्ट है, यह एक तरह का विषय है ... :(

Comments

मैं अंडरस्कोर टाइपिंग के लिए शिफ्ट दबाने के लिए भी थक गया हूं।

— गौथियर

यह चर नाम के लिए संभव नहीं है, क्योंकि "-" का मतलब आमतौर पर माइनस होता है।

— एरिक विल्सन

Answer 13

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

Comments

अच्छी तरह से यह आसान नहीं है क्योंकि आप कहीं भी पढ़ते हैं, यह आसान है क्योंकि यह आपके साथ काम करने वाला पहला था और मुख्य रूप से डीसौस आप इसके लिए अधिक अभ्यस्त हैं, उदाहरण के लिए मैं अंडरस्कोर_केस के साथ अधिक आरामदायक हूं।

— पोइलिन्का

जैसा कि मैंने पढ़ा है कि एक अध्ययन किया गया था और इसे बेहतर पाया गया ..

— रॉस

Answer 14

जैसा कि ज्यादातर लोगों ने उल्लेख किया है - मौजूदा मानक का उपयोग करें। यदि यह एक नई परियोजना है, तो आपके द्वारा उपयोग की जाने वाली भाषा और रूपरेखा के लिए मानक का उपयोग करें।

और भ्रमित मत हो, यह पठनीयता के बारे में नहीं है (जो व्यक्तिपरक है), यह सुसंगत और पेशेवर होने के बारे में है। जो भी कई 'मानकों' के साथ एक कोडबेस में काम किया है वह समझ जाएगा।

Answer 15

मैं कभी-कभी एक मिश्रण का उपयोग करता हूं: mod_FunctionName। मेरे मॉड्यूल में सभी (गैर-स्थिर) फ़ंक्शन मॉड्यूल संक्षिप्त नाम से शुरू होते हैं।

उदाहरण के लिए I2C बस में एक बफर की सामग्री भेजने के लिए एक समारोह:

i2c_BufferSend()

विकल्प i2c_buffer_sendउपसर्ग और फ़ंक्शन नाम के बीच एक बड़ा पर्याप्त अलगाव नहीं दिखाता है। i2cBufferSendमिक्स उपसर्ग में बहुत अधिक (इस मॉड्यूल में काफी संख्या में I2C फ़ंक्शन हैं)।

i2c_Buffer_send एक विकल्प हो सकता है, यद्यपि।

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

myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase। I_respect_the_fact_that_some_could_think_otherwise_but_I_do_not_really_understand_why।

Comments

अंतिम 2 पंक्तियों के लिए +1, हालाँकि मैं आपको नामकरण सम्मेलनों को संयोजित करने के लिए नहीं बताता हूं, आपको एक या दूसरे के साथ रहना चाहिए।

— पोइलिन्का

जब तक सम्मेलन अच्छी तरह से परिभाषित किया गया है (उपसर्ग + अंडरस्कोर + पास्कलकेस) ...

— गौथियर

मैं एक नाम के अलग-अलग हिस्सों में अंडरस्कोर का उपयोग करना पसंद करता हूं, जिनके शब्दार्थ-असहमति के उद्देश्य हैं, खासकर अगर आधे पर या तो समानता महत्वपूर्ण हो सकती है। उदाहरण के लिए, दिनचर्या Motor1_Start(), Motor2_Start(), Motor1_Stop()और Motor2_Stop()एक रिश्ता है कि अंडरस्कोर के बिना कम स्पष्ट हो सकता है है।

— सुपरकैट

Answer 16

व्यक्तिगत रूप से, मैं ऊंट पसंद करता हूं, लेकिन कुछ फोंट में मुझे लगता है कि अंडरस्कोर पढ़ना आसान है।

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

myName   = 7
bobsName = 8   // :(

me.name  = 7
bob.name = 8   // :D

इसी तरह, अगर आपको अलग-अलग प्रकार की ज़रूरत है, तो ऐसी भाषा का उपयोग क्यों न करें जो उन्हें अनुमति देती है?

var intThingy = 7; // :(

int thingy = 7;    // :)

एक बार जब आपके पास वह सीधा हो जाता है, और आप केवल नाम का उपयोग मेटा-डेटा के रूप में नहीं कर रहे हैं, तो आपके पास पर्याप्त लंबे नाम नहीं होंगे कि यह बहुत मायने रखता है कि आप उस अतिरिक्त कीबोर्ड को पसंद करते हैं या नहीं।

Comments

CamelCase या अंडरस्कोर_केस का उपयोग करने के कारणों में से एक यह है कि मुझे वस्तुओं को खोजने की आवश्यकता नहीं है कि यह क्या है।

— जोशुआ शेन लिबरमैन

Answer 17

सबसे पहले, मैं डैफमेटल से सहमत हूं। यह सबसे महत्वपूर्ण है, कि आप विभिन्न प्रोग्रामिंग शैलियों का मिश्रण न करें। एक और एक ही फ़ाइल में ऐसा करना सबसे खराब है जिसे आप IMHO कर सकते हैं। विभिन्न फाइलों के पार, यह विचलित करने वाला है, लेकिन घातक नहीं है।

अगली चीज़ जो आपको करनी है, वह है नामकरण नियमों पर जो उस भाषा के लिए लोकप्रिय हैं, जिसमें आप लिख रहे हैं। मेरा C ++ कोड फ़ॉर इंस्टेंस के लिए, पायथन के लिए किसी चीज़ से अलग दिखेगा, जाहिर है (PEP8 यहाँ एक अच्छा मार्गदर्शक है)

आप विभिन्न चीजों को संदर्भित करने के लिए विभिन्न नामकरण सम्मेलनों का भी उपयोग कर सकते हैं, जितना कि आप शायद UPPER_CASE कांस्टेंट के लिए उपयोग करते हैं (यह केवल कुछ निश्चित भाषाओं पर लागू होता है), आप स्थानीय चर नामों के लिए इस_स्टाइल का उपयोग कर सकते हैं, जबकि आप उदाहरण के लिए camelCase का उपयोग करते हैं / सदस्य चर। जब आपके पास इस तरह की selfया जैसी चीजें हैं, तो इसकी आवश्यकता नहीं हो सकती है this।

अपडेट करें

चलो एक मामला लेते हैं जहां आपके पास मंच है फू चुड़ैल किसी भी नामकरण सम्मेलनों को फिर से शामिल नहीं करता है और यह एक को चुनने के लिए टीम के नेता की पसंद है। आप उस टीम लीडर हैं, आप ऊंट को क्यों चुनेंगे या अंडरस्कोर_केस क्यों।

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

एलेक्स मार्टेली को इसी तरह की बात पर उद्धृत करने के लिए:

निश्चित रूप से, मैं रूबी में, प्रत्येक ब्लॉक के अंत में मूर्खतापूर्ण "अंत" टाइप करने के बजाय थके हुए हो जाता हूं (बल्कि सिर्फ अनुत्तरदायी) - लेकिन फिर मुझे समान रूप से मूर्खतापूर्ण टाइपिंग से बचने के लिए मिलता है ':' जिसे पायथन की आवश्यकता है प्रत्येक ब्लॉक की शुरुआत , ताकि लगभग धुलाई :-)। अन्य वाक्यविन्यास अंतर जैसे '@foo' बनाम 'स्व.फू', या रूबी बनाम पायथन में मामले का उच्च महत्व, वास्तव में मेरे लिए अप्रासंगिक हैं।

दूसरों को कोई संदेह नहीं है, बस ऐसे मुद्दों पर प्रोग्रामिंग भाषाओं की उनकी पसंद है, और वे सबसे गर्म बहस उत्पन्न करते हैं - लेकिन मेरे लिए यह केवल पार्किंसंस कानूनों में से एक का एक उदाहरण है (कार्रवाई पर बहस पर राशि मुद्दे के विपरीत आनुपातिक है वास्तविक महत्व )।

स्रोत

यदि आप टीम लीडर हैं, तो आप सिर्फ एक के साथ जाते हैं। चूंकि एक के पास दूसरे पर कोई लाभ नहीं है, आप केवल पासा फेंक सकते हैं या आपको जो पसंद है उसे उठा सकते हैं।

Answer 18

मैंने कई साल पहले पढ़ा था कि प्रोग्रामर जो पहली भाषा के रूप में अंग्रेजी नहीं बोलते हैं, उस ऊंट मामले को समझने के लिए अंडरस्कोर केस को आसान पाते हैं- लेकिन मुझे संदर्भ नहीं मिल रहा है, और मुझे नहीं पता कि क्या यह सच है।

Answer 19

जावा, पायथन, सी ++ जैसी प्रोग्रामिंग भाषाओं के लिए मैंने एक स्पष्ट प्रारूप अपनाया है:

• ClassNamesArePascalCase
• methodNamesAreCamalCase
• variable_names_are_underscore
• CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES

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

मैंने पास्कलकेस में सख्त और नाम की चीजों को उपयोगी भी पाया है जैसे कि HTML पार्सर के रूप में HTMLParser या HTMLparser के बजाय HtmlParser। क्योंकि मेरा मानना ​​है कि सख्त नियम को याद रखना आसान है और शब्द सीमाएं स्पष्ट रहती हैं (दुर्भाग्य से इसमें HTML या SQL जैसी गलत वर्तनी की आवश्यकता होती है)। इसी तरह camelCase के साथ, HTMLParserMethod के बजाय HTMLParserMethod या HTMLparserMethod।

अद्यतन :

जब से मैंने निजी चर को शामिल करने के लिए इन नियमों के विस्तार में उपयोग पाया है। - _pStreet_variable_names_are_prefixed_with_an_underscore - _PRIVATE_CONSTANT_VARIABLES_ARE_PREFIXED_WITH_AN_UND_CORE

जावा में, इसका मतलब है कि निजी क्षेत्र स्थानीय चर की तुलना में एक अलग नामस्थान में परिभाषा से हैं, जिसका अर्थ है कि आप this.निजी क्षेत्रों पर छोड़ सकते हैं। अन्य स्वरूपों को मैंने " m" के साथ उपसर्ग देखा है , लेकिन वे प्रारूप भी चर नामों के लिए कैमलकेस का उपयोग करते हैं। यह मुझे उन क्षेत्रों के बीच एक अंतर बनाने की भी अनुमति देता है जिसे केवल कक्षा द्वारा आंतरिक रूप से एक्सेस किया जाना चाहिए (और वर्ग के बाहर होने पर यह सुपर स्पष्ट कर रहा object._field_xहै)।

Answer 20

यदि यह मेरे लिए नीचे था, तो मैं किसी विशेष शैली के उपयोग पर लागू या संकेत नहीं करूंगा क्योंकि, प्रोग्रामर के रूप में, हम एक प्रतीक को पढ़ने में सक्षम हो सकते हैं IfItIsInCamelCase या in_underscore_space या यहां तक ​​कि in_SomeOtherStyle और समझें कि इसका क्या अर्थ है। प्रतीक को पार्स करने के लिए समय की एक छोटी राशि खर्च करने के लिए चीजों की बड़ी योजना में कोई महान उपरि नहीं है।

अब, मुझे लगता है कि एक सम्मेलन के लिए मुख्य तर्क यह है कि आप जानते हैं कि फ़ंक्शन / चर नाम का प्रारूप क्या है और इसे देखने की आवश्यकता नहीं है - क्या यह LoadXMLFile, loadXMLFile, LoadXmlFile, load -xml_file है? अब, मैं उस तर्क को यह कहकर प्रतिवाद करूंगा कि "एक आईडीई प्राप्त करें जो अंतर्मुखी शैली ऑटो पूरा करने का समर्थन करता है!" (हालांकि हमेशा संभव नहीं)।

हालांकि अंत में, यह वास्तव में मायने नहीं रखता है कि आप किस शैली का उपयोग कर रहे हैं संकलक / दुभाषिया वास्तव में परवाह नहीं करता है। क्या महत्वपूर्ण है कि नाम उपयोगी है:

NumberOfPrisonersReleasedByAccident
manufacturer_name
distance_EarthToMoon

तीन अलग-अलग शैलियों, लेकिन आप जानते हैं कि वास्तव में प्रत्येक क्या करता है।

Comments

मैं अलग होने के लिए विनती करता हूं, स्रोत की उपस्थिति महत्वपूर्ण है। देखें "व्यावहारिक प्रोग्रामर" खिड़कियों के टूटे सिद्धांत। वैरिंग नामकरण सम्मेलन उपस्थिति को बदतर बनाता है। pragprog.com/the-pragmatic-programmer/extracts/software-entropy

— Gauthier

@ गौथियर: हालांकि मैं 'टूटी खिड़की' के विचार से सहमत हूं, मुझे नहीं लगता कि प्रतीकों का पूंजीकरण एक 'टूटी खिड़की' का गठन करता है। Haphazardly निर्धारित कोड निश्चित रूप से है, और मेरी वर्तमान परियोजना में निश्चित रूप से बहुत कुछ है जो मैं जब भी कर सकता हूं, मुझे साफ करने की कोशिश करता हूं।

— स्किज़ डेस

मैं सहमत हूँ। मैं तीनों को बराबर पढ़ सकता हूं। इससे कोई फर्क नहीं पड़ता। मैं बस जो कुछ भी फाइल का उपयोग कर रहा हूं उसका उपयोग करता हूं, फिर जो भी भाषा प्रस्तावित करता है (अजगर) और फिर जो कुछ भी मुझे लगता है कि वह परियोजना सबसे अच्छा होगा। (मैं gwbasic में प्रोग्राम करता था, और यह सब कैप था - अच्छे पुराने दिन!)

— क्रिस्टोफर महान

Answer 21

मूर्खतापूर्ण लग सकता है, लेकिन मुझे अंडरस्कोर पसंद नहीं है क्योंकि अंडरस्कोर पतला है, और कई लाइन टेक्स्ट में छिपा है और मुझे यह याद है। इसके अलावा, कुछ (कई) पाठ संपादकों और / या देव परिवेशों में, जब आप एक टोकन नाम पर डबल क्लिक करते हैं, तो इसे हाइलाइट करने के लिए इसे कॉपी या ड्रैग और ड्रॉप करने के लिए, सिस्टम पूरे टोकन को हाइलाइट नहीं करेगा, यह केवल एक हिस्से को हाइलाइट करता है टोकन का, आसन्न अंडरस्कोर के बीच। जो मुझे पागल कर देता है।

Answer 22

मैं मूर्खतापूर्ण कारण से कैमलकेस पसंद करना पसंद करता हूं कि मैं अपना अधिकांश विकास एक्लिप्स (जावा, पीएचपी और जावास्क्रिप्ट के लिए) में करता हूं, और जब मैं Ctrl+ ←या Ctrl+ →शब्दों के माध्यम से करता हूं , तो यह वास्तव में कैमसेलसीस सीमाओं पर रुक जाता है।

Ie: myIntVariableग्रहण द्वारा 3 शब्दों के रूप में माना जाएगा जब Ctrl+ ← →इसके माध्यम से आईएनजी।

मुझे पता है कि यह एक अजीब विचित्रता है, लेकिन मुझे लगता है कि खुद को एक कैमलकेस नाम में मध्य शब्दों को संपादित करने में सक्षम होना पसंद है।