कोड डिजाइन

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


विषय के अधिकांश सुझाव मैककॉनेल की पुस्तक "परफेक्ट कोड" (स्टीव मैककोनेल - "कोड कम्प्लीट") से हैं।

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

नियम शून्य : अपने कॉर्पोरेट वातावरण में अपनाई गई कोड शैली "गाइड" का सख्ती से पालन करें।

गुणवत्ता के तरीके

विधि एक स्पष्ट रूप से परिभाषित उद्देश्य की सेवा करनी चाहिए।

इस लक्ष्य को उनके नाम में पूरी तरह से प्रतिबिंबित किया जाना चाहिए: वर्तमान उपयोगकर्ता प्राप्त करें - geturrentUser () । विधि का धुंधला, अस्पष्ट और अति खराब नाम सबसे अधिक बार होता है
इसके असफल कार्यान्वयन के मुख्य साक्ष्य हैं।

अच्छी विधि के नाम के उदाहरण:

ग्राहक :: getFullName () - क्लाइंट का पूरा नाम प्राप्त करें UserMapper :: createAndGetUser (userId) - उपयोगकर्ता-मैपर के संदर्भ में, एक अपवाद, विधि की साइड भूमिका (नए बनाए गए उपयोगकर्ता-ऑब्जेक्ट को वापस करना) काफी स्पष्ट है।

MonthRevenue.calculate (), MonthRevenue.export () - विधि नाम जो अपने आप में सूचनात्मक नहीं हैं, इन विधियों के OOP कॉल के संदर्भ में पूरी तरह से पर्याप्त रूप से "खुद को" कहते हैं (दूसरे शब्दों में, विधि को उस ऑब्जेक्ट पर कार्रवाई करने के लिए डिज़ाइन किया गया है जो इसे और इसके डेटा को कहते हैं)।

खराब विधि के नाम के उदाहरण:

computeMonthRevenueAndDoExport () - कई असंबंधित लक्ष्य
processInput (), handleCalacle () - अनुभवहीनता, लक्ष्य का धुंधला
विधि

• युग्मित विलोम का उपयोग उन तरीकों के लिए किया जाना चाहिए जो युग्मित (विपरीत) क्रियाएं करते हैं: खुला / बंद, दिखाना / छिपाना, जोड़ना / हटाना, सम्मिलित करना / हटाना।
  
• इस विधि को स्वीकार किए गए सम्मेलनों, "कोड शैलियों" आदि के अनुसार सख्त रूप में प्रारूपित किया जाना चाहिए।
  
• विधि को प्रलेखित किया जाना चाहिए (दोनों विधि इंटरफ़ेस स्वयं और महत्वपूर्ण और जटिल अनुभागों पर टिप्पणियाँ)।
  
• विधि को वैश्विक चर को संशोधित नहीं करना चाहिए।
  
• विधि में बहुत अधिक पैरामीटर नहीं होना चाहिए (7 से अधिक नहीं)।
  
• मापदंडों को उनके महत्व की डिग्री या विधि के अंदर उनके उपयोग के क्रम द्वारा आदेश दिया जाना चाहिए:
  

  setMonthExchangeRate (महीने, ExchangeRate)
  getCustomerMonthRevenue (customerId, माह)
  

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

  monthRevenue = fixedValue * 0.6 / इनपुटपराम
  

  
  
• विधि बहुत बड़ी नहीं होनी चाहिए (100 लाइनों से अधिक नहीं)।
  

गुणवत्ता चर

चर को पूरी तरह से प्रतिनिधित्व की जा रही इकाई का वर्णन करना चाहिए।

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

मध्यम लंबाई

चर का नाम लोगों को गुमराह करने के लिए बहुत छोटा नहीं होना चाहिए, लेकिन साथ ही यह बहुत लंबा नहीं होना चाहिए, क्योंकि यह कोड पढ़ने के मामले में बदसूरत है। लंबाई पर्याप्त होनी चाहिए ताकि आपको अपने दिमाग को रैक न करना पड़े।

विनिर्देशक

वैरिएबल नामों में Num के बजाय Count और Index Qualifiers का उपयोग करना चाहिए। यह तर्कसंगत है, क्योंकि वे स्पष्ट रूप से चर (संख्या और संख्या) के उद्देश्य को दर्शाते हैं, लेकिन न्यूम अस्पष्ट दिखता है और कुछ मामलों में भ्रामक हो सकता है।

साइकिल सूचकांक

यह सामान्य है जब 1-3 पंक्तियों के एक छोटे से लूप में एक सूचकांक होता है जिसे I, j या k कहा जाता है। लेकिन अगर चक्र का शरीर काफी बड़ा है, तो सूचकांकों को सार्थक नाम देना बेहतर है। और आपके लिए समय के साथ इस तरह के कोड से निपटना आसान हो जाएगा (यह तुरंत स्पष्ट हो जाता है कि लूप क्या करता है) और अन्य प्रोग्रामर जो आपके कोड के साथ काम करेंगे, वे भी आसान हो जाएंगे।

स्थानांतरण उपसर्ग

गणना का उपयोग करते समय, यह एक उपसर्ग लगाने के लिए समझ में आता है। उदाहरण के लिए, इस तरह के चर STATUS_OPENED, STATUS_TO_CONFIRM, STATUS_CONFIRMED के मामले में, संलयन उपसर्ग STATUS_ के साथ चला जाता है।

स्थिरांक

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

कन्वेंशन का

परिवर्तनीय नामकरण सम्मेलनों का उपयोग किया जाना चाहिए, जो प्रोग्रामर की पूरी टीम को पता होगा। कोड सुसंगत होना चाहिए। इसलिए परियोजना के प्रत्येक प्रतिभागी के लिए इसे समझना बहुत आसान होगा। और इससे कार्य कुशलता बढ़ेगी। सम्मेलन स्पष्ट और सभी के लिए सुलभ होना चाहिए। और हर डेवलपर को इससे चिपकना चाहिए।

कम सामान्यीकृत

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

अच्छे चर नामों के उदाहरण:

कर्मचारीपार्टी, उपयोगकर्तामार्टवर्क्सडेस्काउंट, सालटैक्स, अधिकतमकंप्यूटेड सेलरी

खराब चर नामों के उदाहरण:

x, $ fb, f_ar_type_data, f_obj_result, inputData, returnValue, resultArray, obj1, obj2

• एक अच्छा नियम यह है कि संकरे दायरे के साथ चरों को क्रमशः छोटे नाम दिए जाएँ, अधिक लम्बे और अधिक विस्तृत नामों के साथ अधिक वैश्विक (विधि के ढाँचे के भीतर) दायरे में।
  
• छोटे चक्रों के काउंटर चर के लिए, पारंपरिक एकल-वर्ण नामों की अनुमति है - i, j, k, .... यदि लूप के बाहर वैरिएबल का उपयोग किया जाएगा, तो इसका नाम अधिक अभिव्यंजक और समझने योग्य होना चाहिए:
  
  

  teamScoresCount = 0; teamScores = array(); while (teamScoresIterator.nextScore()) { teamScores[teamScoresCount++] = teamScoresIterator.getCurrentScore(); } foreach ($teamScores as $teamScoreIndex => $teamScoreValue) foreach ($aTeamScores as $iTeamScoreIndex => $iTeamScore) { // over 9000 lines of code } 

  
  
• संक्षिप्त और गैर-स्पष्ट संक्षिप्तताओं से बचें। खराब: सीएल (कॉल स्टैक), जीएफएक्स (ग्राफिक्स), डीटीपी (विभाग)।
  
• केवल सुसंगत संक्षिप्तताओं का उपयोग करें: केवल अधिकतम या केवल अधिकतम; केवल संख्या या केवल नहीं; महीने, या तो पहले तीन अक्षरों (जनवरी, फरवरी, मार्च) या पूर्ण में।
  
• समान मूल्यों वाले नामों से बचें (एक विशिष्ट दायरे के भीतर): fileNumber / fileIndex; स्कोरनंबर / स्कोरकाउंट। केवल एक विकल्प का उपयोग करें। वर्तनी की गलतियों और टाइपोस के बिना नाम लिखें
  
• जब तक वे कार्यक्रम में प्रतिनिधित्व नहीं करते हैं, तब तक सार्थक (केवल आपके लिए) नाम (स्नफ़ी, एलीज़बेथ) के साथ नामकरण चर से बचें।
  
• बूलियन वैरिएबल के नाम पुष्टिकारक रूप में होने चाहिए और बूलियन मूल्य का अर्थ है: किया, त्रुटि, पाया, समाप्त। खराब: स्थिति, स्रोत।
  
• एक चर के दायरे को कम करना:
  
  
  • यथासंभव समान चर का उपयोग करके कमांड की व्यवस्था करें
    एक दूसरे के करीब।
    
  • इनका उपयोग करने से ठीक पहले वैरिएबल को प्रारंभ करें
    
  
  
• केवल एक ही उद्देश्य के लिए प्रत्येक चर का उपयोग करें।
  
• 
  आरंभिक चर डिफ़ॉल्ट रूप से।
  

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

इस कोड को पढ़ने के लिए सहमत:

 function() { $a = 1; $b = 2; $c = 3; $sql = ' SELECT * FROM tbl WHERE a = 1'; } 

से ज्यादा अच्छी है

 function(){ $a = 1; $b = 2; $c = 3; $sql = 'SELECT * FROM tbl WHERE a = 1'; } 

कोड पूरा पुस्तक से लिंक ।
आपका ध्यान देने के लिए धन्यवाद।