एक अच्छे (पढ़ें: उपयोगी) कोडिंग मानक में क्या होना चाहिए?
जवाबों:
हर आवश्यकता के लिए एक कारण। इस तरह, मानक का पालन करना किसी प्रकार के कार्गो पंथ के रूप में नहीं बनता है और लोग जानते हैं कि मानक को बदलना ठीक है यदि इसका कारण अब लागू नहीं होता है, या विशिष्ट मामलों में मानक का उल्लंघन करना है जहां कारण स्पष्ट रूप से लागू नहीं होता है ।
टैब बनाम रिक्त स्थान! मुझे पागल अपडेट तब मिलता है जब मेरे सहयोगियों में से एक गलती से बहुत से टैब को रिपॉजिटरी में रिक्त स्थान में स्थानांतरित कर देता है
नामकरण की परंपरा
EDIT: इसके द्वारा मेरा अर्थ है दिशानिर्देशों का नामकरण, न कि नियमों का नामकरण।
उदाहरण के लिए, एक दिशानिर्देश होगा All boolean values should begin with Is/Can/Has/etc when possible। एक नियम होगाAll boolean values must start with Is
IsCanUpdateऔर IsHasChildren। ज़रूर, यह गलत है, लेकिन यह मानक में कम था। और यह मेरी बात है: एक बार जब आप इन चीजों को निर्दिष्ट करना शुरू कर देते हैं, तो आपको यह सुनिश्चित करना होगा कि आप सभी आधारों को कवर करते हैं, या फिर कुछ लोग मानक को कवर नहीं करते हैं, या बुरी तरह से कवर करते हैं, और फिर वे या तो कुछ लिखते हैं जो गलत है, या वे मानक की अनदेखी करने लगते हैं। किसी भी तरह से, टीम हार जाती है।
एक समूह के लिए एक कोडिंग मानक में चेतावनी और त्रुटियों के लिए संकलक विकल्प शामिल होने चाहिए जिन्हें संबोधित किया जाना चाहिए।
प्रोग्रामर को अपने कोड के लिए चेतावनी बढ़ाने के लिए स्वतंत्र होना चाहिए , लेकिन एक आधार रेखा होनी चाहिए ताकि किसी और के कोड के साथ पढ़ना और काम करना आपके कंपाइलर से प्राप्त आउटपुट को अव्यवस्थित न करे।
इस तरह के मानक को यह भी संबोधित करना होगा कि प्रोग्रामर इस तरह के चेतावनी केस-बाय-केस को कैसे निष्क्रिय कर सकते हैं, क्या कोई असाधारण कोड होना चाहिए जो अन्यथा अनुरूप नहीं होगा।
कुछ मानक जो मुझे पसंद हैं (मुझे पता है कि उनमें से बहुत कुछ है, लेकिन यह वही है जो मुझे पसंद है):
कोडिंग मानक थोड़ी मदद करते हैं जब आप पहली बार कोड लिख रहे होते हैं, तो वे बहुत मदद करते हैं जब आपको या आपके प्रतिस्थापन के लिए 2 साल बाद कोड को अपडेट करना होता है।
आदर्श मानक उस कोड की ओर ले जाता है जहाँ आप कोड में किसी भी मनमाने पेज पर जा सकते हैं, और वास्तव में यह समझ सकते हैं कि यह पहले रीड-थ्रू पर क्या कर रहा है, क्योंकि
दूसरी ओर, बहुत से मनमाने मानक लेखन कोड के प्रवाह को बाधित कर सकते हैं। इसलिए मेरा मानना है कि प्रस्तावित कोडिंग कन्वेंशन के प्रत्येक आइटम का मूल्यांकन इन 2 मानदंडों के विरुद्ध किया जाना चाहिए:
यदि न तो सच है, तो आइटम सिर्फ मनमाना है, और शायद अनावश्यक है
मैं निम्नलिखित चीजों को एक मानक में शामिल करता हूं जो मैं लिखता हूं:
विस्तृत जानकारी के लिए:
फ़ाइल संगठन: किसी फ़ाइल में आइटम के लिए एक निश्चित आदेश निर्दिष्ट करने से टीम आसानी से दूसरों की फ़ाइलों को नेविगेट कर सकती है। आपको # आधार, या संरचना परिभाषा खोजने के लिए शिकार नहीं करना चाहिए।
नामकरण सम्मेलनों: संगत नामकरण पठनीयता एड्स। लेकिन बहुत अधिक नियमों को निर्दिष्ट करने से बचें, जो कि लेखन क्षमता को हानि पहुँचाता है।
कोड संरचना। घुंघराले ब्रेस प्लेसमेंट, इंडेंटेशन स्तर, रिक्त स्थान बनाम टैब आदि। हां, यह एक मजबूत व्यक्तिगत प्राथमिकता हो सकती है, लेकिन लक्ष्य स्पष्ट कोड है। टीम के लिए सबसे अच्छा विकल्प ढूंढें, और इसके साथ रहें।
सुधार के लिए:
आपकी समस्या के प्रकार के लिए विशिष्ट सर्वोत्तम प्रथाएँ: स्मृति आवंटन, या संगामिति, या पोर्टेबिलिटी के बारे में नियम।
"कांस्टेबल सुधार", staticऔर volatileआदि का समुचित उपयोग ।
प्रीप्रोसेसर मैक्रोज़ और भाषा के अन्य आसानी से दुरुपयोग की जाने वाली विशेषताओं के बारे में नियम।
नकारात्मक प्रतिबंधों के बजाय लोगों को सोचने वाले प्रेरक, व्यावहारिक विचार जो लोगों को सोचने से रोकते हैं।
अन्यथा, आपको कोड बंदर मिलते हैं जो केले के बाद जाने से डरते हैं ।
एक कोडिंग मानक में क्या होना चाहिए? जितना कम हो सके उतना। कम बल्कि ज्यादा। और औचित्य के साथ, कृपया।
इसलिए नहीं कि मैं कुछ चरवाहा कोडर हूं, जो कोई प्रक्रिया नहीं चाहते हैं, बल्कि इसलिए कि मैंने इसके पीछे (बिना किसी तर्क के) के साथ भारी कोडिंग चश्मा देखा है (संभवतया) "मुझे यह 'नेट कहीं पर वापस '95 में मिला" जो अंत में बन रहा है एक नौकरशाही दुःस्वप्न के साथ काम करने के लिए।
कुछ लोग ईमानदारी से यह मानते हैं कि मानकों को क्रैंक करने से वे कोड "गुणवत्ता" में एक समान वृद्धि देखेंगे और शायद उस माप से वे करेंगे। इस बीच वे वास्तुकला, प्रदर्शन, सामान्य ज्ञान और एक गुच्छा अन्य चीजों को अनदेखा करेंगे जो एक फ़ाइल में लाइनों की संख्या से अधिक मामले को समाप्त करते हैं।
कुछ अच्छे पुराने सामान्य ज्ञान नहीं चलेंगे; अब तक बहुत से कोडिंग मानक दस्तावेज हैं जो अप्रासंगिक बिंदुओं पर श्रम करते हैं (आइटम जैसे कि फ़ॉन्ट प्रकार और आकार जो मैंने देखे हैं उनमें से एक चरम चरम पर है)।
यदि आप डेवलपर्स के समूह में हैं, तो सबसे अच्छी बात यह है कि आपस में बात करें और अपने कोड को देखें, जो स्वीकार्य है उस पर आम सहमति बनाएं और यदि आपको मुख्य बिंदुओं को दिशानिर्देश के रूप में लिखने की आवश्यकता है, लेकिन उन्हें रखें बस यही दिशा-निर्देश। यदि आप किसी दिशा-निर्देश को सही नहीं ठहरा सकते, तो आपको वास्तव में इस पर विचार करना चाहिए कि आप ऐसा क्यों कर रहे हैं।
दिन के अंत में लेआउट या टाइपोग्राफी पर किसी भी कठोर नियम की तुलना में स्पष्ट और समझने योग्य कोड अधिक महत्वपूर्ण है।
जैसा कि दूसरों ने उल्लेख किया है, कोड परीक्षण कवरेज महत्वपूर्ण है। मुझे भी देखना है:
परियोजना की संरचना। क्या परीक्षण कोड का हिस्सा हैं, या वे एक अलग परियोजना / पैकेज / निर्देशिका में हैं? क्या UI कोड बैक-एंड सामान के साथ रहता है? यदि नहीं, तो इसे कंपार्टमेंटल कैसे किया जाता है?
विकास की प्रक्रिया। कोड से पहले परीक्षण लिखें? क्या टूटी हुई बिल्डिंग्स को ठीक करना विकास पर प्राथमिकता देता है? कोड समीक्षा कब की जाती है, और उन्हें क्या कवर करना चाहिए?
स्रोत कोड प्रबंधन कब में क्या जाँच हो जाती है? क्या डिज़ाइन डॉक्स और टेस्ट प्लान रिवीजन-नियंत्रित हैं? आप कब शाखा देते हैं और कब टैग करते हैं? क्या आप पिछले बिल्ड रखते हैं, और यदि ऐसा है तो कितने / कब तक?
परिनियोजन मानक। एक निर्माण कैसे पैक किया जाता है? रिलीज नोट्स में जाने की क्या जरूरत है? अपग्रेड स्क्रिप्ट को कैसे बनाया / नियंत्रित / चलाया जाता है?
नामकरण सम्मेलनों, स्वरूपण और कितनी लाइनें फ़ंक्शन / विधि / मॉड्यूल में हो सकती हैं के बारे में सभी को भूल जाओ। एक नियम: जो कुछ भी आप संपादन कर रहे हैं, उसमें मौजूदा शैली का उपयोग करें। यदि आपको किसी की शैली पसंद नहीं है, तो इसे एक कोड समीक्षा में अलग करें। एकमात्र अपवाद टैब-बनाम-स्पेस चीज़ हो सकती है, यदि केवल इसलिए कि कई संपादक / आईडीई नेत्रहीन रूप से एक-दूसरे को बदल देंगे, और फिर आप अपने परिवर्तन इतिहास को नष्ट कर देंगे क्योंकि हर पंक्ति बदल गई थी।
मुझे लगता है कि वास्तव में संबोधित करने के लिए दो चीजें हैं, और मैं वास्तव में उन पर अलग से विचार करूंगा क्योंकि उन्हें एक ही तरीके से संपर्क नहीं किया जा सकता है, हालांकि मुझे दोनों महत्वपूर्ण लगते हैं।
तकनीकी पहलू I कोडिंग मानक के योग्य है , जैसा कि हर्ब सटर और आंद्रेई अलेक्जेंड्रेस्कु अपने सी ++ कोडिंग मानकों के साथ करते हैं । प्रस्तुति मैं कोडिंग स्टाइल के योग्य है , जिसमें नामकरण सम्मेलन, इंडेंटेशन, आदि शामिल हैं ...
कोडिंग मानक
क्योंकि यह विशुद्ध रूप से तकनीकी है, एक कोडिंग मानक ज्यादातर उद्देश्य हो सकता है। जैसे कि हर नियम को एक कारण से समर्थन किया जाना चाहिए। पुस्तक में मैंने प्रत्येक आइटम का उल्लेख किया है:
औचित्य और अपवाद बहुत महत्वपूर्ण हैं, क्योंकि वे क्यों और कब का सारांश देते हैं।
शीर्षक पर्याप्त स्पष्ट होगा कि समीक्षाओं के दौरान किसी को काम करने के लिए केवल शीर्षकों (चीट शीट) की सूची की आवश्यकता होती है। और जाहिर है, एक के लिए बाहर देखने के लिए आसान बनाने के लिए श्रेणी के अनुसार आइटम समूह।
सटर और अलेक्जेंड्रेस्कु केवल सौ वस्तुओं की एक सूची रखने में कामयाब रहे, भले ही सी ++ को बाल माना जाता है);
कोडिंग स्टाइल
यह भाग आम तौर पर कम उद्देश्य वाला होता है (और यह व्यक्तिपरक हो सकता है)। यहां इरादा स्थिरता की गारंटी देने का है, क्योंकि इससे रखरखाव और नए काम करने वालों को मदद मिलती है।
आप एक पवित्र-युद्ध में प्रवेश नहीं करना चाहते हैं जिसके बारे में इंडेंटेशन या ब्रेस स्टाइल बेहतर है, इसके लिए फ़ोरम हैं: इसलिए इस श्रेणी में आप सर्वसम्मति से बहुमत से वोट करते हैं> नेता (ओं) द्वारा मनमाना निर्णय।
प्रारूपण के उदाहरण के लिए, कलात्मक शैली के विकल्पों की सूची देखें । आदर्श रूप से, नियम स्पष्ट और पर्याप्त होना चाहिए कि एक प्रोग्राम कोड को फिर से लिख सके (हालांकि यह संभावना नहीं है कि आप कभी भी कोड एक होंगे;);
नामकरण सम्मेलन के लिए, मैं वर्ग / प्रकार को आसानी से चर / विशेषताओं से अलग करने की कोशिश करूंगा।
यह इस श्रेणी में भी है कि मैं "उपायों" को वर्गीकृत करता हूं:
विविध?
और अंतिम शब्द के रूप में, एक आइटम है जो शायद ही कभी होता है, यदि कभी कोडिंग मानकों में चर्चा की जाती है, शायद इसलिए कि यह प्रत्येक एप्लिकेशन के लिए विशेष है: कोड संगठन। वास्तुशिल्प मुद्दा शायद सबसे उत्कृष्ट मुद्दा है, प्रारंभिक डिजाइन पर पेंच और आप इसे अब से वर्षों से ग्रस्त हो जाएंगे। आपको शायद मूल फ़ाइल हैंडलिंग के लिए एक खंड जोड़ना चाहिए: सार्वजनिक / निजी हेडर, निर्भरता प्रबंधन, चिंता का पृथक्करण, अन्य प्रणालियों या पुस्तकालयों के साथ इंटरफेस ...
लेकिन वे कुछ भी नहीं हैं अगर वे वास्तव में लागू और लागू नहीं होते हैं ।
किसी भी उल्लंघन को कोड समीक्षाओं के दौरान लाया जाना चाहिए, और उल्लंघन के बकाया होने पर कोई भी कोड समीक्षा ठीक नहीं होनी चाहिए:
जाहिर है, एक नियम को बदलने का मतलब है नेताओं से "आगे बढ़ना"।
मुझे फ्रेमवर्क डिज़ाइन दिशानिर्देशों में प्रारूप पसंद है, इसमें दिशानिर्देशों के लिए एक सामान्य अनुभाग और तर्क शामिल हैं। सबसे उपयोगी बिट विवरण हैं जो Do, Do Not, Avoid और विचार के साथ शुरू होते हैं।
यहाँ एक उदाहरण है अनुभाग में इंटरफ़ेस सदस्य लागू करना स्पष्ट रूप से इसमें निम्नलिखित आइटम हैं (ध्यान दें कि मैंने बर्बरता के लिए तर्क को गिरा दिया है)
ऐसा करने के लिए एक मजबूत कारण के बिना स्पष्ट रूप से इंटरफ़ेस सदस्यों को लागू करने से बचें
इंटरफ़ेस सदस्यों को लागू करने पर विचार करें यदि सदस्यों को केवल इंटरफ़ेस के माध्यम से बुलाया जाना है।
सुरक्षा सीमा के रूप में स्पष्ट सदस्यों का उपयोग न करें।
करो एक संरक्षित आभासी सदस्य है कि प्रस्तावों ही कार्यक्षमता> स्पष्ट रूप से लागू किया सदस्य के रूप में करता है, तो कार्यक्षमता का मतलब है व्युत्पन्न वर्ग द्वारा विशेष होने के लिए प्रदान करते हैं।
यह एक अच्छा सामान्य स्वर बनाता है। बचें और विचार करके आप डेवलपर्स को अपने फैसले का उपयोग करने की अनुमति दे सकते हैं। इसके अलावा, क्योंकि वे दिशा-निर्देश हैं और नियम नहीं हैं कि डेवलपर्स को उन्हें और अधिक स्वादिष्ट लगने की संभावना है और बदले में उनका पालन करने की अधिक संभावना है।
किसी ने भी उल्लेखित सुरक्षा नहीं की है - एक कोडिंग मानक में आपके पास सुरक्षित कोड आवश्यकताओं (जैसे इनपुट सत्यापन मॉड्यूल का उपयोग, ज्ञात कमजोर कार्यों जैसे strcpy, त्रुटि से निपटने की आवश्यकताओं आदि) को अस्वीकार करना आवश्यक है।
उदाहरण। नीटली व्यवस्थित, गैर-तुच्छ, करीब-करीब वास्तविक दुनिया के उदाहरण जो हर नियम का उपयोग करते हैं। टिप्पणियाँ (जरूरी नहीं कि कोड का हिस्सा) उदाहरण के कौन से भाग किस नियम का अनुसरण करते हैं।
टेम्पलेट्स। सी ++ प्रकार नहीं, लेकिन कॉपी-पेस्ट और लाइव के साथ भरने के लिए कुछ। यह बहुत आसान है कि जब आप से कॉपी करने के लिए एक संदर्भ है तो 24-लाइन बॉयलरप्लेट टिप्पणी करें।
नंबर एक सुविधा: दो पृष्ठों की एक अधिकतम अधिकतम।
यह कुछ ऐसा है जिसे आप हर डेवलपर को पढ़ना और याद रखना चाहते हैं। हर बार आपको एक नया फ़ंक्शन लिखने की ज़रूरत नहीं है (या एक नई लाइन खराब) मानक में नहीं देखना चाहिए। इसलिए, इसे कम रखें और केवल उन नियमों को रखें जो वास्तव में अंतिम उत्पाद को बढ़ा हुआ मूल्य प्रदान करते हैं।
कोडिंग मानकों वास्तव में कई आइटम हैं:
कोडिंग सम्मेलनों
सर्वोत्तम प्रथाएं
पूर्व के लिए। कोशिश के बाद कभी भी खाली कैच न छोड़ें
try { Foo(); } catch { //do nothing }
1) अगर फू () द्वारा फेंका गया कोई अपवाद है, तो यह उन कार्यों पर अन्य मुद्दों का कारण बन सकता है, जो मानते हैं कि फू सफल था।
2) वैश्विक त्रुटि हैंडलर अपवाद की समर्थन टीम को सूचित नहीं करेगा जब यह उत्पादों पर होता है
कोडिंग पर्यावरण
कोडिंग मानकों, जब कागज पर लिखा जाता है, केवल इतना प्रभावी होता है। मुझे यह पसंद है कि कैसे गो अपने कोडिंग मानक को प्रकाशित कर रहा है। इसमें gofmtप्रोग्राम टेक्स्ट को एक फॉर्मेट में फॉर्मेट करने का टूल है। कोडिंग प्रारूप पर किसी भी बहस के बाद परिणाम के स्रोतों के लिए एक पैच के रूप में परिणाम होगा gofmt।
प्रारूप के लिए क्या होना चाहिए,
if, जब यह आता है , फ़ंक्शन बॉडी, किसी अन्य प्रयोजनों के लिए स्टेटमेंट ब्लॉक,जब मैं दूसरों को पढ़ रहा होता हूं (सी भाषा ज्यादातर) कोड, अगर वेरिएबल / फंक्शन नाम प्रोजेक्ट के संदर्भ में सहज नहीं हैं या यदि यह इंडेंटेशन के पांच स्तरों से अधिक है या फ़ंक्शन छह या सात से अधिक तर्क लेते हैं या एक फंक्शन चलता है स्क्रीन पर दो या तीन पृष्ठ, कोड को पढ़ना और समझना बहुत कठिन हो जाता है। जब उस पर एन्हांसमेंट / रखरखाव का काम करने के लिए कहा जाता है, तो यह केवल कठिनाई में जोड़ता है। यह मुझे इस बात की इच्छा करता है कि gofmtहर परियोजना (या यहां तक कि भाषा) के लिए प्रोग्राम लिखा जाए और प्रोजेक्ट में आने से पहले हर सोर्स कोड फाइल को उस प्रोग्राम के माध्यम से चलाया जाए।
मुझे Google जावास्क्रिप्ट स्टाइल गाइड पसंद है ।
इसके दिशानिर्देशों में इसका संक्षिप्त विवरण अभी भी है यदि आपको उनकी आवश्यकता है।