अभिव्यक्तिपूर्ण नाम बनाने के लिए 9 दिशानिर्देश

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

जब एक सॉफ्टवेयर इंजीनियर एक क्लास खोलता है, तो उसे नामों के आधार पर क्लास की जिम्मेदारियों का पता होना चाहिए। हाँ, मुझे पता है कि नामकरण केवल पहिये का एक हिस्सा है, भौतिक और तार्किक संरचनाएं भी कोड को समझने में महत्वपूर्ण भूमिका निभाती हैं जैसे जटिलता भी करती है। इस लेख में, मैं केवल नामकरण पर ध्यान केंद्रित कर रहा हूँ क्योंकि मुझे लगता है कि यह कोड को समझने पर सबसे महत्वपूर्ण प्रभाव डालता है।

प्रकार को शामिल न करें जब तक कि यह इरादे को स्पष्ट न करे

एक प्रकार कुछ भी हो सकता है - एक प्रोग्रामिंग प्रकार (string, int, decimal) से लेकर जिम्मेदारियों का एक समूह (Util, Helper, Validator, Event, आदि)। अक्सर यह एक वर्गीकरण है जो इरादे को व्यक्त नहीं करता है।

आइए एक उदाहरण देखें: नाम StringHelper बहुत कुछ व्यक्त नहीं करता है। एक string एक सिस्टम प्रकार है, और Helper अस्पष्ट है, StringHelper “कैसे” के बारे में अधिक बोलता है इरादे की तुलना में। यदि इसके बजाय, हम नाम को DisplayNameFormatter में बदलते हैं तो हमें इरादे की एक स्पष्ट तस्वीर मिलती है। DisplayName बहुत विशिष्ट है, और Formatter परिणाम को व्यक्त करता है। Formatter एक प्रकार हो भी सकता है और नहीं भी, लेकिन इससे कोई फर्क नहीं पड़ता, क्योंकि यह इरादे को व्यक्त करता है।

हमेशा अपवाद होते हैं; उदाहरण के लिए, ASP.Net MVC में, नियंत्रकों को “Controller” में समाप्त होना चाहिए या एप्लिकेशन काम नहीं करेगी। Domain Driven Design (DDD) जैसे प्रतिमान का उपयोग करते हुए, “Services,” “Repository,” “ValueType” और “Model” जैसे नामों का DDD में अर्थ है और जिम्मेदारी को व्यक्त करते हैं।

उदाहरण के लिए, UserRepository का अर्थ है कि उपयोगकर्ता डेटा को एक डेटा स्टोर से प्राप्त और सहेजा जाता है।

रूपकों से बचें

रूपक सांस्कृतिक हैं, और अन्य संस्कृतियों के इंजीनियर इरादे को नहीं समझ सकते हैं।

संयुक्त राज्य अमेरिका में सामान्य रूपक:

• Beating a dead horse
• Chicken or the egg
• Elephant in the room

न्यूजीलैंड में सामान्य रूपक:

• Spit the dummy
• Knackered
• Hard yakka

क्रिया का उपयोग करें

Steve Yegge ने संज्ञा पर क्रिया का उपयोग करने के बारे में एक (बहुत लंबा) ब्लॉग पोस्ट लिखा है।

उनका बिंदु क्रिया का उपयोग करना है, एप्लिकेशन संज्ञा से बनी होती हैं, लेकिन संज्ञा कुछ नहीं करती हैं। सिस्टम केवल संज्ञा के साथ बेकार हैं, इसके बजाय विधियों के नामों में कार्रवाई को व्यक्त करें।

उदाहरण के लिए, UserAuthentication*(संज्ञा).AuthenticateUser(कार्रवाई/क्रिया)* उपयोगकर्ता के क्रेडेंशियल को सत्यापित करने की कार्रवाई को व्यक्त करता है।

विवरणपूर्ण बनें

विवरणपूर्ण बनें, जितना अधिक विवरण, उतना बेहतर — नाम में जिम्मेदारी को व्यक्त करें।

अपने आप से पूछें, यह क्लास या फ़ंक्शन एक चीज़ क्या अच्छी तरह से करता है?

यदि आपको नाम खोजने में कठिनाई हो रही है, तो क्लास या फ़ंक्शन के पास एक से अधिक जिम्मेदारियां हो सकती हैं और इस प्रकार Single Responsibility Principle का उल्लंघन कर रहे हैं।

इरादे के लिए टिप्पणियों पर निर्भर न रहें

टिप्पणियां कोड को अतिरिक्त संदर्भ प्रदान करने का एक शानदार तरीका हैं लेकिन टिप्पणियों पर निर्भर न रहें। क्लास और विधियों के नाम अपने आप पर खड़े होने चाहिए।

Refactoring: Improving the Design of Existing Code में Martin Fowler, Kent Beck, John Brant, William Opdyke, और Don Roberts द्वारा:

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

“In Refactoring” लेखकों से एक और शानदार उद्धरण:

जब आप एक टिप्पणी लिखने की आवश्यकता महसूस करते हैं, तो पहले कोड को रीफैक्टर करने का प्रयास करें ताकि कोई भी टिप्पणी अनावश्यक हो जाए। पृष्ठ 88

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

कभी-कभी जब एक विधि को कॉल करते हैं तो उपभोक्ता को विधि के बारे में कुछ विशेष जानने की आवश्यकता होती है, यदि वह विशेषता नाम का हिस्सा है, तो उपभोक्ता को स्रोत कोड की समीक्षा करने की आवश्यकता नहीं है।

यहाँ एक टिप्पणी को एक नाम में शामिल करने का उदाहरण दिया गया है।

टिप्पणियों के साथ:

// without tracking
var user = GetUserByUserId(userId);

विधि के नाम में टिप्पणी को शामिल करने के लिए रीफैक्टर किया गया:

var userWithOutTracking = GetUserByUserIdWithoutTracking(userId);

अन्य इंजीनियर अब जानते हैं कि इस विधि में ट्रैकिंग नहीं है इससे पहले कि उन्हें स्रोत कोड को पढ़ने या टिप्पणी को खोजने की आवश्यकता हो।

टिप्पणियां आपकी अंतिम पंक्ति की रक्षा होनी चाहिए जब संभव हो तो इरादे को व्यक्त करने के अन्य तरीकों का लाभ उठाएं जिसमें भौतिक और तार्किक संरचना और नाम शामिल हैं।

अस्पष्ट अर्थ वाले नामों का उपयोग करने से बचें

अस्पष्ट अर्थ वाले नामों से बचें। अस्पष्ट नामों का अर्थ परियोजना से परियोजना में बदलता है जो एक नए इंजीनियर के लिए इरादे को समझना कठिन बनाता है।

यहाँ सामान्य अस्पष्ट नामों की एक सूची दी गई है:

• Helper
• Input
• Item
• Logic
• Manager
• Minder
• Moniker
• Nanny
• Overseer
• Processor
• Shepherd
• Supervisor
• Thingy
• Utility
• Widget

व्यावसायिक डोमेन के समान भाषा का उपयोग करें

कोड में व्यावसायिक डोमेन के समान शब्दावली का उपयोग करें। यह इंजीनियरों और विषय वस्तु विशेषज्ञों (SME) को आसानी से विचारों को संप्रेषित करने की अनुमति देता है क्योंकि वे समान शब्दावली साझा करते हैं। जब कोई साझा शब्दावली नहीं होती है तो अनुवाद होता है जो अनिवार्य रूप से गलतफहमी की ओर ले जाता है।

एक परियोजना में जिस पर मैंने काम किया, व्यावसायिक “Pupil” से शुरू हुआ और फिर “Student” में स्विच किया। सॉफ्टवेयर इंजीनियरों ने कभी भी सॉफ्टवेयर को शब्दावली में परिवर्तन को प्रतिबिंबित करने के लिए अपडेट नहीं किया। जब नए इंजीनियर परियोजना में शामिल हुए तो अधिकांश को विश्वास था कि Pupil और Student विभिन्न अवधारणाएं थीं।

उद्योग की बोली का उपयोग करें

जब संभव हो, उस शब्दावली का उपयोग करें जिसका सॉफ्टवेयर उद्योग में अर्थ है।

अधिकांश सॉफ्टवेयर इंजीनियर, जब वे “factory” नाम की कोई चीज़ देखते हैं, तो वे तुरंत factory pattern के बारे में सोचते हैं।

“Clean Architecture” और “Domain Driven Design” जैसे मौजूदा एप्लिकेशन प्रतिमान का उपयोग करना विचार साझा करने को सुविधाजनक बनाता है और इंजीनियरों के लिए विचारों को संप्रेषित करने के लिए एक सामान्य भाषा बनाता है।

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

बूलियन का नाम देते समय…

बूलियन नाम हमेशा एक प्रश्न का उत्तर होना चाहिए जिसका मान true या false हो।

उदाहरण के लिए, isUserAuthenticated, उत्तर या तो हाँ (true) या नहीं (false) है

इस तरह के शब्दों का उपयोग करें:

• Has
• Does
• Is
• Can

नकारात्मक नामों से बचें, उदाहरण के लिए:

एक नकारात्मक चर नाम:

var IsNotDeleted = true; // this is confusing

if(!IsNotDeleted) { // it gets even more confusing when the value is negated
  //Do magic
}

नकारात्मक चर नाम के बिना:

var IsDeleted = true; // this is confusing

if(!IsDeleted) { 
  //Do magic
}

समापन में

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