जब आपका नामकरण सम्मेलन आपकी भाषा से टकराता है तो आप क्या करते हैं?

14

ठीक है, यह उन छोटी चीजों में से एक है जिन्होंने मुझे हमेशा कमज़ोर किया है। मैं आम तौर पर पहचानकर्ताओं को संक्षिप्त नहीं करता हूं, और केवल एक बार मैं एक छोटे पहचानकर्ता का उपयोग करता हूं (जैसे, i) एक तंग लूप के लिए। इसलिए यह मुझे परेशान करता है जब मैं C ++ में काम कर रहा हूं और मेरे पास एक चर है जिसे नाम देने की आवश्यकता है operatorया classमुझे इसके चारों ओर काम करना है या एक संक्षिप्त नाम का उपयोग करना है, क्योंकि यह चिपके हुए समाप्त होता है। कैविएट: ऐसा मेरे साथ अक्सर हो सकता है क्योंकि मैं प्रोग्रामिंग भाषा डिजाइन में बहुत काम करता हूं, जहां डोमेन ऑब्जेक्ट होस्ट भाषा में अवधारणाओं को मिरर कर सकते हैं और अनजाने में झड़पों का कारण बन सकते हैं।

आप इससे कैसे निपटेंगे? संक्षिप्त? ( op) मिसपल? ( klass) कुछ और? ( operator_)

naming

— जॉन प्यूरी
स्रोत

7

नाम रखने के अलावा शायद हमें अपने नामकरण सम्मेलनों को बदलने पर विचार करना चाहिए? स्पष्ट के लिए क्षमा करें।

— क्रिस

1

@ क्रिस: आप स्पष्ट महसूस करने के लिए एक प्रोग्रामर पर कभी भरोसा नहीं कर सकते हैं! (हालांकि इस मामले में मेरे पास है।)

— जॉन पुरडी

7

यदि PHP के $varसिंटैक्स को पसंद करने का कोई कारण है , तो यह है।

— जोए एडम्स

3

@ जॉय एडम्स: जब मैंने इस प्रश्न को देखा तो मैं थोड़ा मुस्कुराया और एसई के चारों ओर घूमने वाले सभी PHP को कोसने वाले प्रश्नों को याद किया।

— क्रिस

3

जाहिर है, मेरे नामकरण सम्मेलनों की अनुमति देने के लिए भाषा स्रोत कोड बदलें। इससे मेरे कोड को "प्रोटेक्ट" करने का भी लाभ है क्योंकि यह केवल मेरे दुभाषिया / संकलक पर ही चल / संकलित होगा।

— आहारबुध

21

स्वीकार करें कि आपको अपने नामकरण सम्मेलन में छोटे बदलाव करने पड़ सकते हैं, जैसे कि पूंजीकरण जोड़ना। जितनी जल्दी हो सके इसे स्वीकार करना बेहतर है ताकि बाद के सभी कोड सुसंगत हों।
अधिक विशिष्ट होने पर विचार करें। कीवर्ड काफी व्यापक होते हैं, इसलिए न केवल मुद्दों के आसपास काम classकरने से कम होता है , demonstrationClassबल्कि पठनीयता भी बढ़ती है।

— Maxpm
स्रोत

10

यह कुछ ऐसा नहीं है जिसका मैंने सामना किया है, लेकिन अगर मुझे ऐसी स्थिति में मिलता है, तो मैं इसे निम्नलिखित विकल्पों के साथ हल करने की कोशिश करूंगा, ताकि आदेश में।

एक समानार्थी शब्द खोजने का प्रयास करें।
(विशेष रूप से चर के लिए) एक उपसर्ग या उपसर्ग खोजने की कोशिश करते हैं
(विशेषकर कक्षाओं के लिए) पहले अक्षर को अपर-केस में बदल देते हैं और कोडिंग-नियम के बारे में भूल जाते हैं कि नाम केवल मामले में भिन्न नहीं होने चाहिए। यह विकल्प, मैं शायद केवल तभी उपयोग करूंगा जब संघर्ष किसी कीवर्ड के साथ हो।
एक संक्षिप्त नाम का उपयोग करें।

— बार्ट वैन इनगेन शेनौ
स्रोत

1

मैं यह नहीं देखता कि केवल मामले में भिन्न नामों के साथ क्या गलत है, विशेष रूप से तर्क सूचियों में जहां प्रकार के पैरामीटर के अलावा const Foo&कोई अन्य पूर्ण नाम नहीं है foo। दी, यह बेहतर हो सकता है कि आपके शरीर को Fooएक अधिक विशिष्ट नाम दिया जाए, जैसे fooकि यह एक फ़ंक्शन बॉडी में रहता है और एक कम विशिष्ट उद्देश्य प्रदान करता है।

— जॉन प्यूरी

@Jon - मैं सहमत हूं, हालांकि व्यक्तिगत रूप से मैं केस-अलग होने के बजाय "p_", "l_" और "m_" उपसर्गों की ओर जाता हूं। मैंने उस सम्मेलन को सर्व-समान-स्पष्ट-नाम मुद्दे के कारण अपनाया। इससे निपटने के लिए आप किस अधिवेशन का उपयोग करते हैं, यह काफी हद तक अप्रासंगिक है, जब तक कि आप इसे किसी विशेष संदर्भ में लगातार उपयोग करते हैं, निश्चित रूप से - केस-अलग-अलग दृष्टिकोण निश्चित रूप से पर्याप्त रूप से पर्याप्त रूप से उपयोग किया जाता है कि अधिकांश डेवलपर्स को इसे पहचानना चाहिए।

— स्टीव 314

@Jon - उस टिप्पणी को पढ़ता है जैसे मैं चुनिंदा रूप से सम्मेलन को लागू करता हूं जब मेरे पास समान-नाम का मुद्दा होता है, जो कि मेरा मतलब नहीं है। संदर्भ मुद्दा भाषा, परियोजना आदि से संबंधित है। कन्वेंशनों को डिज़ाइन किया गया है ताकि जब भी ऐसा हो (या बल्कि नहीं), तो समस्या के रूप में चयनित नहीं किया जा सके।

— स्टीव ३४

@ स्टीव ३१४: पहली टिप्पणी से मुझे आपका अर्थ मिल गया। मुझे पता नहीं है, इस तरह के शपथपत्र हमेशा मेरे आराम के लिए सिस्टम हंगेरियन के बहुत करीब महसूस करते थे।

— जॉन पुरडी

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

— बार्ट वैन इनगेन शेनौ

6

भाषा जीतती है; आप कंपाइलर को बहिष्कृत नहीं कर सकते (पीएल / 1 जैसे घृणा को अनदेखा कर सकते हैं IF IF = THEN THEN THEN = ELSE ELSE ELSE = IF END, लेकिन फिर पीएल / 1 आपको पहली जगह में सवाल पूछने का कारण नहीं बनाएगा)। मूल रूप से, आपको भाषा के नियमों का पालन करना होगा, और आपको अपने स्वयं के उपयोग के लिए भाषा के प्रमुख शब्दों का विकल्प ढूंढना होगा - या एक वैकल्पिक भाषा ढूंढनी होगी।

इसलिए, बहुत ही असामान्य परिस्थितियों को छोड़कर, आप भाषा के अनुकूल हैं, न कि इसके विपरीत।

— जोनाथन लेफ़लर
स्रोत

5

संक्षिप्त के बारे में कैसे? यदि आप एक वर्ग निर्माण को फू भाषा में लागू कर रहे हैं, तो FooClass और foo_class का उपयोग कैसे करें? (मोडुलो जो भी आपके आवरण की प्राथमिकताएं हैं)।

— विंस्टन इवर्ट
स्रोत

क्या आप जावा कोड में उपयोग किए जाने वाले प्रत्येक पहचानकर्ता पर "जावा" उपसर्ग करेंगे? और हर पहचानकर्ता पर "C ++" को उपसर्ग करने के साथ समस्याओं का उल्लेख भी नहीं करता है ...

— स्टीव ३१४

@ स्टीव 314, आप जावा कोड में उपसर्ग जावा का उपयोग नहीं करेंगे, आप सी ++ कोड में उपसर्ग जावा का उपयोग करेंगे जो एक जावा संकलक को लागू करता है। इसके अलावा, आप इसका उपयोग केवल तभी करेंगे जब बाकी पहचानकर्ता एक कीवर्ड था।

— विंस्टन इवर्ट

ठीक है - आपका मतलब है सामान्य शब्दों में, जैसा कि अधिक विशिष्ट होने में पहचानकर्ता को भी संदर्भित करता है। विभिन्न अनुप्रयोगों के लिए, "वर्ग" का नाम बदलकर "class_taught" या "class_of_animal" या "classiness_value" या जो भी हो। मैं सहमत हूँ - मैं सिर्फ संकलक उन्मुख उदाहरण को भ्रामक पाया।

— स्टीव ३४

5

classआवृत्ति के क्रम में मैंने कुछ संक्षिप्तीकरण का उपयोग किया है :

cls
clss
clazz
theClass
aClass

अगर मुझे पता है कि किस वर्ग का Classप्रतिनिधित्व करता है, तो मैं इसे चर नाम में शामिल कर सकता हूं:

stringClass = Class.forName("java.lang.String");

— माइक क्लार्क
स्रोत

इससे पहले कभी भी 'cls' नहीं देखा। मैं ज्यादातर aClass का उपयोग करता हूं।

— कॉन्स्टेंटिन पेट्रूखनोव

4

C और C ++ में, कीवर्ड्स सभी लोअरकेस हैं और भाषा संवेदनशील है, इसलिए समय-समय पर शिफ्ट की दबाएं और बहुत सारे मुद्दे चले जाएं।

मोडुला 2 में, कीवर्ड सभी बड़े होते हैं - लेकिन जब तक आपके पहचानकर्ताओं के पास कुछ निचले अक्षर होते हैं, तब तक अंतर स्पष्ट और क्लैश असंभव होता है।

इसके अलावा, कुछ हद तक नामकरण परंपराएं आपके द्वारा उपयोग की जाने वाली भाषा के सामान्य सम्मेलनों को प्रतिबिंबित करने की आवश्यकता होती हैं, इसलिए मैं निश्चित रूप से जावा में "myClass" लिखूंगा जहां मैं संभवतः C ++ में "My_Class" लिखूंगा।

असल में, आप केवल संकलक के लिए नहीं लिख रहे हैं, लेकिन लोगों को जो पढ़ने योग्य लगता है वह कुछ हद तक संदर्भ और संबंधित अपेक्षाओं पर निर्भर करता है।

— steve314
स्रोत

3

यहां तक कि केस-संवेदी भाषाओं के लिए, मुझे लगता है कि इंटरमिक्स होने classऔर Classकोड की पठनीयता पर चोट होगी।

— कर्मस्थन

@ कर्मस्थान - शायद यह निर्भर करता है कि आपने केस-संवेदी भाषाओं और सम्मेलनों के साथ काम करने में कितना समय लगाया है। व्यक्तिगत रूप से, ऊपरी बनाम निचला "सी" नेत्रहीन बहुत स्पष्ट है - मैं लंबे पहचानकर्ताओं के लिए केस उपयोग पैटर्न देखता हूं जितना मैं उन्हें पढ़ सकता हूं।

— स्टीव 314

3

मैं अक्सर इसमें भाग नहीं लेता, लेकिन जब मैं ऐसा करता हूं तो यह एक गैर-मुद्दा बन जाता है क्योंकि मैं डेल्फी का उपयोग करता हूं और यह आपको पहचानकर्ता के लिए a & prepending द्वारा इस मुद्दे के आसपास काम करने की अनुमति देता है। तो "वर्ग" एक मान्य पहचानकर्ता नहीं है, लेकिन "और वर्ग" है।

— मेसन व्हीलर
स्रोत

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

— स्टीव ३४

2

मैं चर नाम में किसी प्रकार का नाम जोड़ने वाला हूं। उदाहरण के लिए, मान लें कि आपके पास उपयोगकर्ता नाम का मॉड्यूल है तो मैं चर नाम ऑपरेटर को user_operator या userOperator जैसा कुछ होने के लिए संशोधित करूंगा।

— Pemdas
स्रोत

2

बस "सुचारू", "नहीं", या "मेरे" का उपयोग उपसर्ग के रूप में न करें

— स्टीवन ए। लोव

2

पूर्ण रूप से। मैं "जॉन_पुर्डीस_केयरली_कोसेन_इंडेंटिफायर_प्रिंस__ वोट करता हूं।

— स्टीव ३१

1

@Steven: इससे भी बदतर यह मैं देख रहा हूँ a, anऔर theशुरुआत सीएस छात्रों द्वारा आवृत्ति को परेशान करने के साथ प्रयोग किया।

— जॉन प्यार्इ

1

@Jon Purdy, यह हमारी गलती नहीं है! उस प्रोफेसर को दोष दें जिसने अपनी कक्षा के लोगों के उदाहरण का नाम तय किया है () aPerson।

— बेन एल

@Jon: नामकरण सम्मेलन, जहां मैं काम करता हूं, यह निर्दिष्ट करता है कि स्थानीय चर aतंग पाश चर के अलावा शुरू होने चाहिए : /

— Matthieu M.

2

मेरे नामकरण सम्मेलन को बदलें या समायोजित करें

— Muad'Dib
स्रोत