अभिव्यंजक नाम बनाने के लिए 9 दिशानिर्देश

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

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

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

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

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

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

उदाहरण के लिए, UserRespository का तात्पर्य है कि उपयोगकर्ता डेटा को पुनर्प्राप्त किया जाता है और डेटा स्टोर में सहेजा जाता है।

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

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

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

• 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 का उल्लंघन हो रहा है।

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

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

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

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

“In Refactoring” लेखकों का एक और अद्भुत उद्धरण:

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

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

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

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

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

// 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 हो।

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

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

• Has
• Does
• Is
• Can

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

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

var IsNotDeleted = true; // यह भ्रमित करने वाला है

if(!IsNotDeleted) { // जब मान को नकारा जाता है तो यह और भी भ्रमित करने वाला हो जाता है
  //Do magic
}

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

var IsDeleted = true; // यह भ्रमित करने वाला है

if(!IsDeleted) { 
  //Do magic
}

समापन में

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