क्या छोटे पहचानकर्ता बुरे हैं? [बन्द है]

Question

क्या छोटे पहचानकर्ता बुरे हैं? कोड की समझ के साथ पहचानकर्ता की लंबाई कैसे संबंधित है? पहचानकर्ताओं के नामकरण के बाद क्या अन्य कारकों (कोड समझ के अलावा) पर विचार हो सकता है?

बस उत्तर की गुणवत्ता को बनाए रखने की कोशिश करें, कृपया ध्यान दें कि विषय पर कुछ शोध पहले से ही है!

संपादित करें

जिज्ञासु कि हर कोई या तो यह नहीं सोचता है कि लंबाई प्रासंगिक है या बड़े पहचानकर्ताओं को पसंद करते हैं, जब दोनों लिंक जो मैंने प्रदान किए हैं वे संकेत देते हैं कि बड़े पहचानकर्ता हानिकारक हैं!

टूटी हुई कड़ी

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

• http://evergreen.loyola.edu/chm/www/Papers/SCP2009.pdf

Comments

डेटा बिंदु। मेरा पसंदीदा छोटा पहचानकर्ता है :, जैसे कि :(){ :;:& };:- मैं कहूंगा कि ज्यादातर लोग सोचते हैं कि यह बहुत बुरा है। ;)

@fennec: फोर्क बम होते हैं।

— जोश के

स्टैकओवरफ़्लो के इस सवाल की जाँच करें कि हर प्रोग्रामर को जो किताब पढ़नी चाहिए, उसके अभ्यास के बारे में एक टिप्पणी है ।

— स्लू

सिर्फ इसलिए कि लंबे नामों से बचा जाना चाहिए इसका मतलब यह नहीं है कि आपको लघुता के लिए उन्हें छोटा करने के लिए अतिरिक्त प्रयास करना चाहिए।

— जेएफओ

@cessor अजीब बात है कि अनुसंधान के बारे में इरादा था कि कुछ राय-आधारित के रूप में बंद कर दिया गया था। दुख की बात है कि मैं सहमत हूं, इसके जवाब मिले।

— डैनियल सी। सोबरल

Answer 1

सबसे अच्छा "नियम" मैंने सुना है कि नाम लंबाई चर के दायरे की लंबाई के आनुपातिक होनी चाहिए। तो एक सूचकांक iठीक है अगर लूप का शरीर कुछ पंक्तियाँ लंबी है, लेकिन मुझे कुछ अधिक वर्णनात्मक का उपयोग करना पसंद है यदि यह 15ish लाइनों से अधिक लंबा हो जाता है।

Comments

मैंने ऐसा कभी नहीं सुना है, और मुझे नहीं लगता कि यह सिद्धांत कोड की पठनीयता में सुधार करेगा।

— निमचम्पस्की 12

@ नी: मैं सहमत हूं। यहां तक ​​कि एक छोटे forलूप में, मैं सूचकांक, customerCounterया कुछ का नाम बताऊंगा। यह न्यूनतम अतिरिक्त प्रयास लेता है और आपके कोड को इतना बेहतर बनाता है। छोटे दायरे के लिए छोटे चर का उपयोग करना आलसी होने का बहाना लगता है।

— कोई नहीं

हम्म, यह एक नियम या मेरे लिए एक दिशानिर्देश नहीं है, लेकिन आपको लंबाई के बारे में सोचने का एक तरीका है और इस संदर्भ में यह कुछ समझ में आता है। मैं निश्चित रूप से आलस्य के लिए इसका बहाना नहीं सोचता (हालांकि मैं सहमत हूं कि कुछ इसे ऐसे ही ले सकते हैं)। मेरे पहचानकर्ता लंबे समय से अधिक नहीं हैं (अब जल्द ही पास्कल सिखाये जाने के संकेत) सिवाय इसके कि जब मुझे लिनाक क्वेश्चन और लैम्ब्डा एक्सप्रेशंस जैसी चीजें मिलती हैं, जहां 1, 2, या 3 कैरेक्टर आइडेंटीफायर (आमतौर पर टाइप इनिशियल) मुझे समझ में आने लगते हैं। ।

— मर्फ़

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

— जेरेमी

+1 - का उपयोग iऔर jकर रहे हैं आम नाम है कि हर डेवलपर IMO को समझने के लिए सक्षम होना चाहिए।

— theCloudlessSky

Answer 2

प्रत्येक चर का एक अर्थ होना चाहिए, और इसका नाम उस अर्थ का एक हिस्सा है। और एक बहुत ही महत्वपूर्ण हिस्सा है, क्योंकि यह पाठक को यह समझने में मदद करता है कि एल्गोरिथ्म में गहरी खुदाई के बिना यह क्या है। i, jस्पष्ट रूप से सूचकांकों के रूप में इस्तेमाल किया जा सकता है, वे कम हैं, लेकिन बहुत जानकारीपूर्ण हैं। bntबदसूरत है, closeया closeButtonसार्थक हैं। इसलिए छोटा या लंबा होना चर नाम का सबसे महत्वपूर्ण मानदंड नहीं है, यह सार्थक होना चाहिए। अर्थपूर्णता दृढ़ता से संदर्भ पर निर्भर करती है। उदाहरण के लिए, आप nस्थानीय स्ट्रिंग चर की तरह बहुत छोटा नाम दे सकते हैं, जिसका उपयोग कोड के एक छोटे ब्लॉक में 10 पंक्तियों के लिए किया जाता है और एक संपत्ति के नाम को संदर्भित करता है ( vमूल्य के लिए एक और उदाहरण है)।

तो चर नाम जानकारीपूर्ण होना चाहिए और इससे कोई फर्क नहीं पड़ता कि वे कम या लंबे हैं ।

Comments

+1, और सिर्फ नोट करने के लिए, क्लोज और क्लोजबटन या तो पर्यायवाची नहीं हैं। बंद एक क्रिया है, और इस प्रकार, एक फ़ंक्शन या विधि का नाम होना चाहिए। जबकि क्लोज़बटन एक संज्ञा है, और, जाहिर है, उस बटन का नाम होना चाहिए जो करीबी फ़ंक्शन को ट्रिगर करता है।

— कैफीक्यू

पास एक विशेषण है, उदाहरण के लिए close = true;)

— आर्मंड

Answer 3

मैं एक पहचानकर्ता का उपयोग करूंगा जो लंबाई के बावजूद, चर का वर्णन करता है।

मैं, जम्मू और कश्मीर के मामले अपने आप में इतने सर्वव्यापी हैं कि वे स्वयं वर्णन कर रहे हैं, आप स्वचालित रूप से जानते हैं कि वे लूप इंडेक्स हैं। आप इसके लिए भी यही कह सकते हैं:

foreach loop (Strings s : myString)

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

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

Comments

BTW, लूप संकेतों के लिए i, j और k का उपयोग FORTRAN के 50+ वर्ष पीछे चला जाता है। I के माध्यम से I के अक्षरों से शुरू होने वाले चर प्रकार के डिफ़ॉल्ट रूप से होते हैं। चर जो किसी अन्य अक्षर से शुरू होते हैं, वे डिफ़ॉल्ट REALs के होते हैं। इसने स्वाभाविक रूप से आई-जे, और के का उपयोग लूप इंडेक्स के लिए किया। (फोरट्रान सम्मेलन संभवतः गणित समीकरणों में इस्तेमाल होने वाले इन चरों के उपयोग से पहले आया था।)

— tcrosley

मैंने जो दूसरा पेपर जोड़ा है, उससे पता चला है कि "केवल नकारात्मक पक्ष प्रभाव" टिप्पणी का खंडन करते हुए, कोड को समझने की क्षमता को कम करने वाले बहुत लंबे वर्णनात्मक पहचानकर्ता कम हो जाते हैं।

— डैनियल सी। सोबरल

बहुत लंबे पहचानकर्ताओं का वास्तविक नकारात्मक पक्ष प्रभाव पठनीयता में है। यह एक नज़र में बताना मुश्किल है कि क्या दो बहुत लंबे पहचानकर्ता समान हैं या अलग-अलग हैं, और बहुत लंबे पहचानकर्ताओं के साथ अभिव्यक्ति के सभी तत्वों को चुनना मुश्किल हो सकता है।

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

tcrosley - मैं इसे सिर्फ इसलिए जोड़ूंगा क्योंकि यह फोरट्रान से आता है इसलिए इस तरह की प्रथा को जारी रखने का कोई कारण नहीं है। मैं "i", "j", "k", इत्यादि इट्रेटर / लूप काउंटरों के उपयोग को दृढ़ता से हतोत्साहित करता हूं, यह सादा बौद्धिक आलस्य है। सर्वव्यापी <> अच्छा है।

— quickly_now

Answer 4

वे भ्रामक पहचानकर्ताओं के रूप में बुरे नहीं हैं। मुझे उस डिबगिंग कोड से कोई आपत्ति नहीं है जिसमें पहचानकर्ता केवल एक अक्षर हैं, लेकिन जिस क्षण अलग-अलग नामकरण सम्मेलनों में आते हैं, यह कष्टप्रद है। जैसे, यदि आप कहीं देखते हैं strPersonID, और फिर कहीं और देखते हैं s_EmployeeID, तो यह बताने के लिए भ्रमित है कि क्या ये दोनों तार हैं और क्या कोई अंतर है। इसके अलावा अगर चर कॉपी-पेस्ट ( pmapIntString = new std::map<int,int>) हैं और पूरी तरह से गलत हैं, तो मुझे चिंता होगी।

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

Answer 5

मैं संघर्ष करता हूँ...

मैं हमेशा पहचानकर्ता के रूप में वर्णनात्मक नाम का उपयोग करता हूं, लेकिन बाद में मैंने बहुत कम पहचानकर्ता का उपयोग किया है।

मुझे लगता है, यह कोड के संदर्भ पर निर्भर करता है:

• यदि आपका लेखन जटिल कार्य (एल्गोरिदम) करता है, तो हमेशा कम पहचानकर्ता (एकल वर्ण सर्वोत्तम होते हैं) का उपयोग करें
• कार्यों के लिए पैरामीटर मान लिखते समय वर्णनात्मक नाम का उपयोग करें।

मुझे लगता है कि यह इस बात पर भी निर्भर करता है कि कोड कितना घना है। कभी-कभी नाम होने से वास्तव में इसे पढ़ना अधिक कठिन हो जाता है।

कभी-कभी बिना इसके पूरी तरह से गुप्त नाम के!

Comments

यदि आप जटिल एल्गोरिदम लिख रहे हैं, हालांकि, क्या आप नहीं चाहेंगे कि पहचानकर्ता पहली बार आपके कोड को देखने वाले लोगों के लिए अधिक वर्णनात्मक बनें?

— मैक्सएमएम

एक एकल चरित्र पहचानकर्ता कब उपयुक्त है?

— अमीर अफगानी

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

— अंधेरी

मैं सहमत हूं, लेकिन केवल एक लंबे जटिल सूत्र के लिए, क्योंकि वे बहुत लंबा हो जाते हैं, और तब भी आप फ़ंक्शन (फ़ंक्शन नाम) का उपयोग करके यह बता सकते हैं कि उस सूत्र के कौन से भाग हैं।

— एमिल व्रजदग्ज

यदि यह ऐसा जटिल है, और इसमें पैटर्न हैं, तो उन पैटर्नों को कार्य में तोड़ दिया जाना चाहिए

— CaffGeek

Answer 6

मेरी सोच यह है कि वे अपने आप में बुरे नहीं हैं लेकिन जब तक वे बहुत मानक नहीं हैं तब तक वे एकरूप नहीं हैं।

इसलिए लूप वैरिएबल i, j और k इतने मानक हैं कि यदि आप इंडेक्स लूप बना रहे हैं तो उनका उपयोग न करने का कोई कारण नहीं है।

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

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

Answer 7

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

Answer 8

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

अगर यह एक इतिहास है कि यह सुबोध बनाता है एक बहुत ही कम चर नाम उपयोगी केवल है (जैसे, i, j, और k, सूचकांक के लिए dxया एक गुंजाइश छोटे पर्याप्त के लिए सभी संदर्भों को एक ही बार में दिखाई दे सकता है है कि एक धुरी के साथ एक दूरी के लिए) (जैसे , temp)। दुनिया में सबसे खराब चर नाम की चीजें हैं t47। ("इसका क्या मतलब है और यह अलग क्यों है t46?") अच्छाई का धन्यवाद कि नामकरण की शैली ज्यादातर फोरट्रान के साथ चली गई, लेकिन यह वह जगह है जहां लंबे समय तक चर नामों की इच्छा निहित है।

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

जैसा कि NoteToSelf ने पहले बताया था, एक नाम की विशिष्टता के लिए आवश्यकताएं मुख्य रूप से उस दायरे पर निर्भर करती हैं जिसका नाम अद्वितीय होना चाहिए। 5-लाइन लूप का सूचकांक हो सकता है i; एक सक्रिय रिकॉर्ड का एक सूचकांक जो फ़ंक्शन से फ़ंक्शन में पास हो जाता है, उसमें बेहतर विवरणात्मक नाम होता है।

किसी कार्य के लिए एक स्थानीय चर deltaXसमस्या के बिना एक छोटे वर्णनात्मक नाम हो सकता है। किसी मॉड्यूल में एक स्थिर डेल्टा X चर में एक ऐसा नाम होना चाहिए जो इस डेल्टा को अन्य डेल्टा के समान मॉड्यूल से अलग करता है, जिससे यह लंबे समय तक बना रहता है। और एक वैश्विक डेल्टा X चर को सभी मॉड्यूलों और सभी संभावित अन्य मॉड्यूलों के लिए अद्वितीय बनाया जाना चाहिए, जो संभवतया मॉड्यूल नाम को अन्य वर्णनात्मक नाम से मिलाते हुए। यह ग्लोबल्स के साथ कई समस्याओं में से एक है; उपयोगी रूप से अद्वितीय होने के लिए नामों को पढ़ने के लिए उन्हें कठिन बनाने के लिए लंबा होना चाहिए।

Answer 9

इसके विपरीत, मुझे लगता है कि लंबे पहचानकर्ता छोटे पहचानकर्ताओं (जब तक आप स्थिरांक के साथ काम नहीं कर रहे हैं) से भी बदतर हैं। उपयोग करने TheVariableThatHoldsTheCapacityOfMyContainerClassसे आपके कोड को उपयोग करने की त्रुटियों से बहुत अधिक खतरा होता है Capacity।

Comments

आपको यह जानकर प्रसन्नता होगी कि जिन शोधों में से एक को मैंने आपके तर्क से जोड़ा है, यदि उन्हीं कारणों से नहीं, तो। ;-)

— डैनियल सी। सोबरल

बहुत लंबे पहचानकर्ताओं को गलत तरीके से समझना भी आसान है, संभवतः उन्हें भ्रमित करना या संभवतः यह महसूस करने में विफल होना कि उनमें से दो समान हैं।

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

TheVariableThatHoldsTheCapacityOfMyContainerClass मैं "लंबा" के रूप में संबंध होगा से बड़ा है - CamelCase की मदद के लिए दस शब्द बहुत लंबा है; आपको पठनीय बनाने के लिए रिक्त स्थान की आवश्यकता है।

— रिचर्ड गड्सडेन

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

— चार्ल्स ई। ग्रांट

@Maxpm, var total = Capacity + Capacity2; क्या Capacityशामिल है, और क्या Capacity2शामिल है? उनका उपयोग किस लिए किया जाएगा? संदर्भ सुराग समय बर्बाद करने के लिए देखने के लिए। जबकि अगर यह लिखा है जैसा कि var totalStorageCapacity = truckCapacity + trailerCapacity;मुझे पता है कि हम किस बारे में बात कर रहे हैं।

— कैफ़ीक्यूक

Answer 10

में, और खुद की, छोटी पहचानकर्ता खराब नहीं हैं। अच्छे नामों (छोटे या लंबे) को चुनने का उद्देश्य कोड स्पष्टता की सेवा में है। कोड स्पष्टता की सेवा में पहचानकर्ता चुनना कुछ न्यूनतम लंबाई आवश्यकता को पूरा करने से अधिक महत्वपूर्ण है। सामान्य तौर पर इसका अर्थ यह है कि यह थोड़ा अधिक सार्थक नाम लिख रहा है।

Comments

+1 आपने इसे बहुत अच्छी तरह से कहा है, जब मैंने उत्तर लिखा है तो मैं अपने शब्दों को नहीं पा सका हूं :-)

— ComputerSaysNo

Answer 11

एक अवलोकन जो मेरे पास वर्षों से है और यह आज की तुलना में 10 या 15 साल पहले की तुलना में कम है। प्रोग्रामर जो टाइप नहीं कर सकते हैं वे हैं जो आपको चर नामकरण पर दांत और नाखून से लड़ेंगे। वे सभी 1-3 अक्षर चर नामों के साथ हैं।

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

Comments

मैंने वास्तव में ऐसा कोई संबंध नहीं देखा है। यदि कुछ भी ऐसा लगता है कि ओओ भाषाओं के लोग लंबे पहचानकर्ताओं के लिए जाते हैं, और कार्यात्मक भाषा के लोग कम लोगों के लिए जाते हैं। यह इस सवाल पर सवाल खड़ा करता है कि OO मॉडलिंग में मदद करता है। :-)

— डैनियल सी। सोबरल

यह मत भूलो कि नामों को न केवल टाइप किया जाना चाहिए, बल्कि पढ़ना भी चाहिए। बहुत लंबे पहचानकर्ताओं का उपयोग वास्तव में पठनीयता को बहुत कम कर सकता है। कुछ भी का उपयोग करना है, लेकिन iजैसे एक पाश में for (int i=0; i<dst.size(); ++i) dst[i] += src[i]कानून द्वारा निषिद्ध किया जाना चाहिए।

— महाआरती

Answer 12

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

मुझे डर है कि मैंने दूसरा पेपर सिर्फ मूर्खतापूर्ण पाया। पहली समस्या यह है कि उनके द्वारा प्रदान किए जाने वाले लंबे नामों के उदाहरण बिना किसी अतिरिक्त जानकारी के प्रदान किए गए हैं। मुझे लगता है कि हम सभी इस बात से सहमत हो सकते हैं कि एक परिवर्तनीय नाम को केवल लंबे समय तक बनाना बेवकूफी है। Dx के बजाय एक परिवर्तनीय दूरी_बेटन_कैस्किसा का नामकरण करने का उनका उदाहरण एक पुआल आदमी है।

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

Comments

ध्यान दें कि दूसरे पेपर में स्पष्ट रूप से कहा गया है कि "आठ सवालों में इस्तेमाल किए गए आठ नाम उत्पादन कोड से निकाले गए थे।" इसके अलावा, वे अकेले याद रखने के लिए नहीं, बल्कि शुद्धता के लिए भी परीक्षा देते हैं।

— डैनियल सी। सोबरल

Answer 13

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

यह कहना आसान है कि "किसी को भी यह समझने में सक्षम होना चाहिए कि मैं, जम्मू और कश्मीर लूप वेरिएबल हैं"। और ज्यादातर बार यह वास्तव में स्पष्ट है। लेकिन मैं अभी भी इस बारे में विनम्र और पेशेवर बने रहने की कोशिश करता हूं और यह मानता हूं कि प्रोग्रामिंग करते समय गलतियां करना आसान है। तो अगर मैं Grobbles की एक सरणी के माध्यम से पाशन कर रहा हूँ तो मैं लूप चर grobbleIndex का नाम दूंगा। मैं भी सूचकांक के एक संक्षिप्त नाम के रूप में स्वीकार कर सकता हूं। जब आप ij और k का उपयोग कर रहे हैं, तो यह त्रुटि के लिए कठिन है जैसे कि गलत इंडेक्स के साथ गलत इंडेक्स का उपयोग करना इत्यादि। और यह और भी बदतर हो जाता है जब आपके पास एक आंतरिक लूप होता है।

पुनश्च। जिस समय मैंने यह उत्तर लिखा था, मैं 10 "मिनी लैपटॉप पर कुछ वर्टिप्ट को कोड कर रहा था, जिसमें एक अलग से विभाजित स्क्रीन थी, और मैंने अभी भी अपने लूप वेरिएबल्स रोइंडेक्स और कॉलमइंडेक्स का नाम लिया था।

Answer 14

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

Answer 15

मुझे लगता है कि आदर्श यह है कि जब तक नाम वर्णनात्मक न हों ...

यह विचार कि नाम हो सकता है (शायद) कम होना चाहिए - और इस प्रकार निहितार्थ से कम वर्णनात्मक - अगर उनके पास सीमित गुंजाइश है तो केवल एक तो आदर्श से विचलित करने कारण है।

व्यक्तिगत रूप से मैं बार-बार संदर्भित संस्थाओं की एक छोटी संख्या के लिए अक्सर छोटे नामों का उपयोग करता हूं। उदाहरण के लिए, अक्सर एप्लिकेशन-विशिष्ट सबरूटीन्स।

Answer 16

मैं 4-5 से कम वर्ण वाले पहचानकर्ता नामों का उपयोग कभी नहीं करूंगा, उदाहरण के लिए एक लूप वैरिएबल इंडेक्स या jIndex या kIndex हो सकता है जो इस बात पर निर्भर करता है कि मुझे कितने आंतरिक छोरों से कुछ हासिल करना है, लेकिन अन्य नामों के लिए "कुंजी" का उपयोग करें। "स्ट्रिंग LKey" या "int LKey", "L" स्थानीय के लिए अगर यह एक विधि चर या निजी वर्ग चर के लिए "F" है, तो अन्य सभी पहचानकर्ता जैसे कि मेरे द्वारा उल्लेख किए जाने से पहले इसका उल्लेख होने का कारण स्पष्ट करना चाहिए, अन्यथा "पहचानकर्ता" गुंजाइश बेकार है यह नहीं है ?!

Comments

"इंडेक्स" क्या अतिरिक्त जानकारी प्रदान करता है जो "i" नहीं करता है? लंबे चर नाम जो आपको कुछ भी नहीं बताते हैं वे एकल-चरित्र वाले से भी बदतर हैं।

— आनन।

हाल ही में 3 डी ग्रिड पर काम करने वाले कुछ सामानों को लिखने के बाद मेरे पास x, y और z नाम के कई वैरिएबल थे। संदर्भ को देखते हुए वे पूरी तरह से वर्णनात्मक थे।

— लोरेन Pechtel