लंबे नाम बहुत लंबे हैं

नमस्कार, हेब्र! मैं आपके लिए बॉब निस्ट्रॉम के लेख "लॉन्ग नेम्स आर लॉन्ग" का अनुवाद प्रस्तुत करता हूं।

Google जिन स्मार्ट चीजों को करता है उनमें से एक है सख्त कोड समीक्षा। प्रत्येक परिवर्तन, इससे पहले कि आप इसे मुख्य शाखा में बनाने की अनुमति दें, कम से कम दो दिशाओं में माना जाता है। सबसे पहले, टीम पर कोई व्यक्ति यह सुनिश्चित करने के लिए एक नियमित जांच करता है कि कोड वह क्या करता है।

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

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

लेकिन, किसी भी मामले में, यह मामला नहीं है। लानत है, यह डार्ट्स भी नहीं है। जो मैं बात करना चाहता हूं वह वही है जो मैं कई कोड में देखता हूं, और जो मुझे पागल करता है: अति लंबे नाम ।

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

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

मैंने 60 से अधिक वर्णों के चर नाम देखे। आप वहां हाइकु या कोआन रख सकते हैं (और संभवतः पाठक को आपके द्वारा चुने गए नाम से अधिक ज्ञानवर्धक है)। लेकिन डर नहीं, मैं यहाँ मदद करने के लिए हूँ।

एक अच्छा नाम चुनना

प्रोग्रामिंग में किसी भी नाम के दो लक्ष्य हैं:

• नाम स्पष्ट होना चाहिए: आपको यह जानना होगा कि इसका क्या मतलब है।
• नाम सटीक होना चाहिए: आपको यह जानना होगा कि यह किस पर लागू नहीं होता है।

एक बार जब नाम इन लक्ष्यों को प्राप्त कर लेता है, तो कोई भी अतिरिक्त वर्ण मृत वजन होता है। यहां कुछ दिशानिर्देश दिए गए हैं जिनका उपयोग मैं अपने कोड में चीजों को नाम देने के लिए करता हूं:

1. उन शब्दों से बचें जो एक चर या पैरामीटर प्रकार में स्पष्ट रूप से निर्दिष्ट हैं

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

इसे देखते हुए, चर नाम में प्रकार को इंगित करना अनावश्यक है। हमने सिर्फ हंगेरियन नोटेशन को छोड़ दिया। जाने दो और भूल जाओ :

 // : String nameString; DockableModelessWindow dockableModelessWindow; // : String name; DockableModelessWindow window; 

विशेष रूप से संग्रह के लिए, एक बहुवचन संज्ञा का उपयोग करना लगभग हमेशा बेहतर होता है एक संग्रह का वर्णन करने वाले एकवचन संज्ञा की तुलना में सामग्री का वर्णन करना। यदि पाठक को इस बात की अधिक परवाह है कि संग्रह में क्या है, तो शीर्षक को प्रतिबिंबित करना चाहिए।

 // : List<DateTime> holidayDateList; Map<Employee, Role> employeeRoleHashMap; // : List<DateTime> holidays; Map<Employee, Role> employeeRoles; 

यह विधि नामों पर भी लागू होता है। विधि के नाम को इसके मापदंडों या उनके प्रकारों का वर्णन करने की आवश्यकता नहीं है - मापदंडों की सूची आपके लिए यह करेगी।

 // : mergeTableCells(List<TableCell> cells) sortEventsUsingComparator(List<Event> events, Comparator<Event> comparator) // : merge(List<TableCell> cells) sort(List<Event> events, Comparator<Event> comparator) 

इससे कॉल बेहतर तरीके से पढ़ी जा सकती हैं:

 mergeTableCells(tableCells); sortEventsUsingComparator(events, comparator); 

क्या यह सिर्फ मुझे है, या यहाँ एक प्रतिध्वनि है?

2. उन शब्दों से बचें जो नाम की अवहेलना नहीं करते हैं

कुछ लोग एक चर के नाम पर कुछ के बारे में जानने के लिए सब कुछ धक्का देते हैं। याद रखें कि नाम एक पहचानकर्ता है : यह उस स्थान को इंगित करता है जहां इसे परिभाषित किया गया है। यह सब कुछ की एक विस्तृत सूची नहीं है जिसे पाठक वस्तु के बारे में जानना चाह सकता है। परिभाषा इसे बेहतर बनाएगी। नाम ही उसे वहां पहुंचाएगा।

जब मैं recentlyUpdatedAnnualSalesBid गए नाम के रूप में देख रहा हूँ

• क्या कोई अद्यतन वार्षिक बिक्री आदेश हैं जो नवीनतम नहीं हैं?
• क्या कोई हालिया वार्षिक बिक्री अनुरोध है जिसे अपडेट नहीं किया गया है?
• क्या कोई हाल ही में अद्यतन वार्षिक गैर-बिक्री एप्लिकेशन हैं?
• क्या हाल ही में अद्यतन किए गए वार्षिक बिक्री डेटा हैं जो बोली नहीं हैं?

यदि इनमें से कम से कम एक प्रश्न का उत्तर "नहीं" है, तो यह आमतौर पर नाम में एक अतिरिक्त शब्द को इंगित करता है।

 // : finalBattleMostDangerousBossMonster; weaklingFirstEncounterMonster; // : boss; firstMonster; 

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

3. उन शब्दों से बचें जो संदर्भ से स्पष्ट हैं।

मैं इस पैराग्राफ में "I" शब्द का उपयोग कर सकता हूं क्योंकि आप जानते हैं कि यह पाठ बॉब Nystrom का है। मुझे यहां "बॉब निस्ट्रोम" को लगातार दोहराने की जरूरत नहीं है (बॉब निस्ट्रोम के प्रलोभन के बावजूद (इस तरह से बॉब निस्ट्रॉम को मजबूत करने के लिए)। कोड बिल्कुल वैसा ही काम करता है। वर्ग के संदर्भ में एक विधि या क्षेत्र होता है। एक चर एक विधि के संदर्भ में होता है। इस संदर्भ को ध्यान में रखें और इसे दोहराएं नहीं।

 // : class AnnualHolidaySale { int _annualSaleRebate; void promoteHolidaySale() { ... } } // : class AnnualHolidaySale { int _rebate; void promote() { ... } } 

व्यवहार में, इसका मतलब है कि गहरा नाम अंतर्निहित है, इसके आसपास के संदर्भ में अधिक है। नतीजतन, यह पता चला है कि यह नाम छोटा होगा। नतीजतन, आप एक पैटर्न देख सकते हैं: पहचानकर्ता जो एक संकीर्ण क्षेत्र में हैं उनके छोटे नाम हैं।

4. ऐसे शब्दों से बचें जिनका कोई मतलब नहीं है।

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

ज्यादातर मामलों में, ये शब्द डेवलपर के लिए कोई सार्थक जानकारी नहीं रखते हैं। आमतौर पर, संदेह ऐसे शब्दों पर आते हैं जैसे: data , state , amount , value , manager , engine , object , entity और instance ।

एक अच्छा नाम पाठक के दिमाग में एक तस्वीर पेश करता है। कुछ भी "प्रबंधक" कहते हुए, हम पाठक को इस बारे में कोई जानकारी नहीं देते हैं कि इस वस्तु को क्या करना चाहिए। क्या यह एक प्रदर्शन मूल्यांकन गणना करता है? अपने कर्मचारियों के लिए पदोन्नति को बढ़ावा देता है?

अपने आप से पूछें: "क्या इस नाम का मतलब वही होगा अगर मैं उस शब्द को हटा दूं?" यदि हाँ, तो यह शब्द कोई मायने नहीं रखता है - द्वीप से बाहर निकालो।

करने के लिए मैनुअल लागू ... waffles

आपको यह पता लगाने के लिए कि ये नियम व्यवहार में कैसे काम करते हैं, यहाँ एक उदाहरण है जो इन सभी का उल्लंघन करता है। यह वंचित उदाहरण वास्तविक कोड के समान है, जो कोड समीक्षा पर मेरे सामने आता है।

 class DeliciousBelgianWaffleObject { void garnishDeliciousBelgianWaffleWithStrawberryList( List<Strawberry> strawberryList) { ... } } 

पैरामीटर के प्रकार के लिए धन्यवाद, हम जानते हैं कि विधि स्ट्रॉबेरी (# 1) की एक सूची को स्वीकार करती है। आइए इस जानकारी को एक नाम से काटें:

 class DeliciousBelgianWaffleObject { void garnishDeliciousBelgianWaffle( List<Strawberry> strawberries) { ... } } 

यदि कार्यक्रम में किसी अन्य राष्ट्रीयताओं के बेस्वाद बेल्जियम वफ़ल या वफ़ल नहीं हैं, तो हम सभी विशेषणों को सुरक्षित रूप से त्याग सकते हैं (# 2):

 class WaffleObject { void garnishWaffle(List<Strawberry> strawberries) { ... } } 

यह विधि WaffleObject अंदर है, इसलिए इस संदर्भ से हम जानते हैं कि यह वास्तव में क्या सजाने वाला है (# 3):

 class WaffleObject { void garnish(List<Strawberry> strawberries) { ... } } 

जाहिर है कि यह एक वस्तु है। ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग (# 4) में सब कुछ एक वस्तु है:

 class Waffle { void garnish(List<Strawberry> strawberries) { ... } } 

अब बहुत बेहतर है।

मुझे लगता है कि ये बहुत सरल सिफारिशें हैं। आपको यह सोचने का अधिकार है कि इस तरह के trifles के बारे में चिंता करना बेकार है। लेकिन मेरा मानना ​​है कि नामकरण सबसे मौलिक कार्यों में से एक है जिसे हम प्रोग्रामिंग करते समय करते हैं। नाम वह संरचना है जो हम बिट्स के आकारहीन समुद्र पर लगाते हैं, जो कि कंप्यूटर है।