comments - What is your personal approach/take on commenting? -


डुप्लिकेट

एक डेवलपर मैं काम करता हूं के साथ कुछ बातें टिप्पणी करने के बारे में कहना है कि मेरे लिए दिलचस्प थे (नीचे देखें) आपका निजी दृष्टिकोण क्या है / टिप्पणी करना?

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

" मुझे लगता है कि टिप्पणी करने के लिए कुछ कैंप हैं, प्रवेशकर्ता-प्रकार जो सोचते हैं कि वे एक एपीआई लिख रहे हैं और कुछ भव्य कोड-लाइब्रेरी जो आने वाली पीढ़ियों के लिए उपयोग की जाएगी, शिल्पकार-जैसे प्रोग्रामर जो मानता है कि कोड क्या कहता है I क्या टी एक टिप्पणी से स्पष्ट करता है, और नौसिखियाँ जो वर्बोज़ / अस्पष्ट कोड लिखते हैं ताकि नोटों को स्वयं के रूप में छोड़ने की ज़रूरत हो कि वे कुछ क्यों करते हैं। "

"स्व-दस्तावेजीकरण कोड" सिद्धांत के साथ एक दुखद दोष है। हां, कोड पढ़ना आपको बताएगा कि यह है क्या कर रहा है हालांकि, यह कोड आपको यह बताता है कि माना ऐसा करने के लिए असमर्थ है।

मुझे लगता है कि यह कहना सुरक्षित है कि जब कोड ऐसा नहीं कर रहा है, तो सभी बग़ कारण होता है कर रही हो :)। इसलिए अगर हम पर्याप्त जानकारी के साथ रखरखाव प्रदान करने के लिए कुछ महत्वपूर्ण टिप्पणियां जोड़ते हैं तो पता करने के लिए कि कोड का एक टुकड़ा क्या करना है, तो हमने उन्हें बहुत सारी बग्स को ठीक करने की क्षमता दी है।

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

मैंने नियमित रूप से निम्नलिखित स्थानों में सबसे उपयोगी टिप्पणियां पाई हैं:

1) एक संक्षिप्त विवरण वर्ग के उद्देश्य को समझाए जाने वाले वर्ग के लिए .h या .cpp फ़ाइल के ऊपर। यह सभी अनुक्रमों को छूने के बिना, एक त्वरित अवलोकन के लिए रखरखाव को देने में मदद करता है।

2) एक गैर-तुच्छ समारोह के क्रियान्वयन से पहले एक टिप्पणी ब्लॉक और इसके अपेक्षित इनपुट, संभावित आउटपुट, और फ़ंक्शन कॉल करते समय अपेक्षा करने के लिए कोई भी विषमताएं। इससे भविष्य के रखवाले को इन कार्यों को समझने के लिए पूरे कार्यों को समझने से बचाया जा सकता है।

इसके अलावा, मैं किसी भी चीज़ पर टिप्पणी करना पसंद करता हूं जो किसी को भ्रमित या अजीब लग सकता है। उदाहरण के लिए: "यह सरणी 1 ब्ला ब्ला के कारण आधारित 0 के स्थान पर आधारित है।"

अच्छी तरह से लिखित, अच्छी तरह से रखी गई टिप्पणियां अमूल्य हैं खराब टिप्पणियां अक्सर किसी भी टिप्पणी से बदतर नहीं होती हैं मेरे लिए, किसी भी टिप्पणी की कमी से कोड के लेखक के भाग पर आलस्य और / या अहंकार का संकेत मिलता है। कोई फर्क नहीं पड़ता कि यह आपके लिए कितना स्पष्ट है कि कोड क्या कर रहा है या आपका कोड कितना बढ़िया है, यह एक चुनौतीपूर्ण कार्य है कि कोड के एक शरीर में आने के लिए और यह पता चले कि क्या हो रहा है।

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


Comments