कंप्यूटर साइंस में केवल दो कठिन चीजें हैं: कैश अमान्य होना
और चीजों का नामकरण।
- फिल कार्लटन
हम, डेवलपर्स, इसे लिखने की तुलना में अधिक समय पढ़ने के कोड में बिताते हैं। कोड को पठनीय होना और उसके इरादे के बारे में स्पष्ट होना महत्वपूर्ण है।
नीचे कुछ सलाह मेरे अनुभव के आधार पर नामकरण की हैं।
अर्थ
एक नाम, यह एक चर हो सकता है, एक संपत्ति, एक वर्ग, या एक इंटरफ़ेस, इसका उद्देश्य प्रतिबिंबित होना चाहिए कि इसे क्यों पेश किया जा रहा है और इसका उपयोग कैसे किया जाता है।
सटीक नामों का उपयोग करें
यदि किसी को अतिरिक्त टिप्पणियों के बिना उपयोग और उद्देश्य के बारे में एक विचार नहीं मिल सकता है तो नाम पर्याप्त अच्छा नहीं है। यदि नामकरण के आधार पर तत्काल उपयोग या उद्देश्य का विचार गलत है तो नामकरण अस्वीकार्य है।
सबसे खराब नामकरण तब होता है जब कोई विधि नाम उस व्यक्ति के पास होता है जो इसे पढ़ता है।
व्यर्थ नामों से बचें
ये $i , $j , $k आदि जैसे नाम हैं। जबकि ये चक्रों में उपयोग करने के लिए ठीक हैं, अन्य मामलों में वे पठनीयता को बर्बाद कर रहे हैं।
ऐसे नामों का एक सामान्य स्रोत क्लासिक विज्ञान है, जहां अधिकांश सूत्र एक-अक्षर वाले चर का उपयोग करते हैं, इसलिए यह लिखना तेज है। नतीजतन, आप नामकरण की व्याख्या किए बिना परिचयात्मक पैराग्राफ के बिना इन सूत्रों का अर्थ नहीं बना सकते हैं। अक्सर इस अनुच्छेद को खोजना मुश्किल होता है।
चूंकि कंप्यूटर विज्ञान शिक्षा में बड़ी संख्या में क्लासिक विज्ञान विषय शामिल हैं, इसलिए छात्रों को इस तरह के नामकरण के लिए इस्तेमाल किया जा रहा है और इसे प्रोग्रामिंग में लाया जा रहा है।
नामकरण कक्षाएं, इंटरफेस, गुण और विधियाँ
कक्षा का नाम एक या कई संज्ञा होना चाहिए। कोई क्रिया नहीं होनी चाहिए। "डेटा", "प्रबंधक", "जानकारी", "प्रोसेसर", "हैंडलर", "निर्माता", "उपयोग" आदि से बचने की कोशिश करें। जैसा कि आमतौर पर अस्पष्ट नामकरण का सूचक है।
इंटरफेस आमतौर पर या तो संज्ञा या विशेषण होते हैं। PHP-FIG सहित कुछ टीमों ने इंटरफ़ेस के साथ पोस्टफ़िक्स इंटरफेस को चुना। कुछ I उपसर्ग के साथ करते हैं और कुछ उपसर्ग या उपसर्ग का उपयोग नहीं करते हैं। मुझे यह सब स्वीकार्य लगता है अगर आप सुसंगत हैं।
गुणों को संज्ञा या विशेषण के साथ नामित किया जाना चाहिए। बूलियंस के लिए "इस्स", "कैन", या "हैस" के साथ उपसर्ग करने वाले सकारात्मक वाक्यांशों का उपयोग करें जहां उपयुक्त हो।
विधि नाम में एक या अधिक क्रियाएं होनी चाहिए क्योंकि वे क्रियाएं हैं। वह क्रिया चुनें जो यह बताती है कि विधि क्या करती है, न कि यह कैसे करती है।
जबकि यह कड़ाई से आवश्यक नहीं है, बेस क्लास के नाम के साथ व्युत्पन्न वर्ग नाम को समाप्त करना एक अच्छा विचार है:
class Exception {} class InvalidArgumentException extends Exception {}
संगति
एकल अवधारणा के लिए एकल नाम का उपयोग करें। सुसंगत रहें।
एक अच्छा उदाहरण start / finish साथ मिलाने के बजाय हर जगह start / end का उपयोग finish ।
कोड शैली सम्मेलनों का पालन करें
प्रोजेक्ट विकसित करते समय, एक टीम को कोड शैली और उन नामकरण सम्मेलनों पर सहमत होना चाहिए जो वे उपयोग करते हैं और इनका पालन करते हैं। यदि कुछ टीम के सदस्यों द्वारा सम्मेलनों का एक हिस्सा स्वीकार नहीं किया जाता है, तो इसकी समीक्षा की जानी चाहिए, बदल दी जानी चाहिए और नया नियम निर्धारित किया जाना चाहिए।
PHP के लिए वर्तमान में सबसे आम सम्मेलन PSR-2 है और अधिकांश आंतरिक परियोजना सम्मेलन इस पर आधारित हैं।
शब्दाडंबर
नामों का पुन: उपयोग करने से बचें
कई अवधारणाओं के लिए एक ही नाम का उपयोग करने से बचना चाहिए यदि संभव हो तो दो समस्याएं लाता है:
- पढ़ते समय, आपको संदर्भ को ध्यान में रखना होगा। आमतौर पर इसका मतलब है कि नाम स्थान या पैकेज घोषणा को लगातार प्राप्त करना।
- ऐसे नामों की खोज एक दर्द है।
संकुचन से बचें
संकुचन का उपयोग न करें। आम उदाहरण हैं:
function cntBigWrds($data, $length) { $i = 0; foreach ($data as $iter) { if (mb_strlen($iter) > $length) { $i++; } } return $i; } $data = ['I', 'am', 'word']; echo cntBigWrds($data, 3);
ठीक से नाम हो जाने पर उपरोक्त कोड:
function countWordsLongerThan(array $words, int $minimumLength) { $count = 0; foreach ($words as $word) { if (mb_strlen($word) > $minimumLength) { $count++; } } return $count; } $words = ['I', 'am', 'word']; echo countWordsLongerThan($words, 3);
अभी भी ध्यान दें कि संकुचन के बिना लघु व्याख्यात्मक नाम लंबे व्याख्यात्मक नामों से बेहतर हैं, इसलिए processTextReplacingMoreThanASingleSpaceWithASingleSpace() नाम के साथ चरम अंत तक क्रियाशीलता न लें, जैसे कि processTextReplacingMoreThanASingleSpaceWithASingleSpace() ।
यदि नाम बहुत लंबा है, तो इसका मतलब यह है कि इसे फिर से छोटा करने के लिए फिर से शब्द दिया जा सकता है या जिस चीज का आप नामकरण कर रहे हैं वह बहुत अधिक कर रहा है और इसे कई चीजों में वापस लाया जाना चाहिए।
टालमटोल से बचें
HTML जैसे सामान्य रूप से ज्ञात लोगों को छोड़कर परिवर्णी शब्द और संक्षिप्तिकरण से बचें। एलोन मस्क ने मई 2010 में सभी SpaceX कर्मचारियों को "परिवर्णी शब्द गंभीरता से चूसो" शीर्षक से एक ईमेल भेजा:
स्पेसएक्स पर बने समरूपों का उपयोग करने के लिए रेंगने की प्रवृत्ति है। बने हुए समरूपों का अत्यधिक उपयोग संचार के लिए एक महत्वपूर्ण बाधा है और जब हम बढ़ते हैं तो संचार को अच्छा बनाए रखना अविश्वसनीय रूप से महत्वपूर्ण है। व्यक्तिगत रूप से, यहाँ कुछ योग और वहाँ इतना बुरा नहीं लग सकता है, लेकिन अगर एक हजार लोग इसे बना रहे हैं, तो समय के साथ परिणाम एक विशाल शब्दकोष होगा जो हमें नए कर्मचारियों को जारी करना होगा। कोई भी वास्तव में इन सभी योगों को याद नहीं कर सकता है और लोग एक बैठक में गूंगा नहीं दिखना चाहते हैं, इसलिए वे सिर्फ अज्ञानता में बैठते हैं। यह नए कर्मचारियों पर विशेष रूप से कठिन है।
इसे तुरंत रोकने की जरूरत है या मैं कठोर कार्रवाई करूंगा - मैंने वर्षों में पर्याप्त चेतावनी दी है। जब तक किसी परिचित को मेरे द्वारा अनुमोदित नहीं किया जाता है, उसे स्पेसएक्स शब्दकोष में प्रवेश नहीं करना चाहिए। यदि कोई मौजूदा ब्योरा है जो उचित रूप से उचित नहीं हो सकता है, तो इसे समाप्त कर दिया जाना चाहिए, जैसा कि मैंने अतीत में अनुरोध किया है।
उदाहरण के लिए, परीक्षण खड़ा करने के लिए "एचटीएस" [क्षैतिज परीक्षण स्टैंड] या "वीटीएस" [ऊर्ध्वाधर परीक्षण स्टैंड] पदनाम नहीं होना चाहिए। वे विशेष रूप से गूंगे हैं, क्योंकि उनमें अनावश्यक शब्द हैं। हमारे परीक्षण स्थल पर एक "स्टैंड" स्पष्ट रूप से एक परीक्षण स्टैंड है। वीटीएस -3 "ट्राइपॉड" की तुलना में चार सिलेबल्स है, जो दो है, इसलिए खूनी संक्षिप्त संस्करण वास्तव में नाम की तुलना में कहने में अधिक समय लेता है!
एक परिचित के लिए मुख्य परीक्षा यह पूछना है कि क्या यह संचार में मदद करता है या चोट पहुँचाता है। एक अनुमान जो स्पेसएक्स के बाहर के अधिकांश इंजीनियरों को पहले से ही पता है, जैसे कि जीयूआई, उपयोग करने के लिए ठीक है। हर बार फिर से कुछ योग्य / संकुचन करना भी ठीक है, यह मानकर कि मैंने उन्हें मर्लिन 1C-वैक्यूम या मर्लिन 1C-Sea लेवल के बजाय MVac और M9 मंजूर किया है, लेकिन उन्हें कम से कम रखा जाना चाहिए।
मैं उससे सहमत हूं।
पठनीयता
कोड को आसानी से गद्य के रूप में पढ़ा जा सकता है। उन शब्दों को चुनें जिन्हें आप एक लेख या किताब लिखना पसंद करेंगे। उदाहरण के लिए, TotalAmount नामक एक प्रॉपर्टी, TotalAmount की तुलना में अंग्रेजी में अधिक पठनीय है।
कार्यान्वयन विवरण छिपा रहा है
यह ऑब्जेक्ट ओरिएंटेड डिज़ाइन के बारे में अधिक है लेकिन कार्यान्वयन विवरण के उजागर होने पर यह पठनीयता को बहुत प्रभावित करता है। इस तरह नामित तरीकों को उजागर न करने की कोशिश करें:
initializeinitcreatebuild
डोमेन भाषा
कोड को उसी नाम का उपयोग करना चाहिए जो व्यवसाय या डोमेन मॉडल में स्वचालित रूप से उपयोग किया जाता है।
उदाहरण के लिए, यदि कैफ़े, होटल और पर्यटक आकर्षणों के लिए एक सामान्य नाम के रूप में "स्थल" का उपयोग करने वाला एक यात्रा व्यवसाय, कोड में "स्थान" का उपयोग करना एक बुरा विचार है क्योंकि आप और आपके उपयोगकर्ता इसे अलग-अलग बनाने के लिए दो अलग-अलग भाषाएं बोलेंगे। चाहिए इससे।
ऐसी भाषा को अक्सर "द उबिकिटस लैंग्वेज" कहा जाता है। आप InfoQ द्वारा " डोमेन ड्रिवेन क्विक क्विकली" मिनी-बुक से अधिक जान सकते हैं।
अंग्रेजी
अधिकांश प्रोग्रामिंग लैंग्वेज बिल्ट-इन कंस्ट्रक्शन के लिए अंग्रेजी का उपयोग करती हैं और साथ ही अंग्रेजी में चीजों को नाम देना एक अच्छा अभ्यास है। एक डेवलपर के लिए कम से कम बुनियादी स्तर पर अंग्रेजी सीखना बहुत महत्वपूर्ण है और अच्छी शब्दावली के लिए एक शब्द का उपयोग करने के लिए अच्छी शब्दावली का होना बहुत जरूरी है।
कुछ उपयोगी उपकरण:
संदर्भ