क्या आप कोड टिप्पणियों में शीर्षक लिखते हैं? [बन्द है]


17

मैं कुछ पुराने कोड को ब्राउज़ कर रहा था जो मैंने लिखा था (विश्वविद्यालय में प्रथम वर्ष) और मैंने देखा कि मैं कोड के विभिन्न भागों से पहले टिप्पणी शीर्षक लिखता था। सामान की तरह (यह एक एकाधिकार खेल से है):

/*Board initialization*/
...code...

/*Player initialization*/
...code...

/*Game logic starts here*/
/*Displaying current situation*/
...code...

/*Executing move*/
...code...

/*Handle special event*/
...code...

/*Commit changes, switch to next player*/
...code...

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

जवाबों:


24

यह एक कोड गंध है। यह कहता है कि क्या और क्यों नहीं ।

यदि यह आवश्यक है, तो कोड को छोटे कार्यों में विभाजित करें।


4
कार्य करने के लिए कार्य करने का कोई मतलब नहीं है।
पॉल नाथन

30
सही है: यदि कोड एक टिप्पणी की तरह है /*Board initialization*/, तो यह संभवतः एक फ़ंक्शन में होना चाहिए InitializeBoard। यदि आपकी कोड संरचना पर्याप्त रूप से स्पष्ट है तो आपको टिप्पणियों की आवश्यकता नहीं होगी।
टिम रॉबिन्सन

3
"क्या" जानना अच्छा है, और अक्सर कोड को देखने से स्पष्ट नहीं होता है। ये टिप्पणियां समग्र इरादे को स्पष्ट करती हैं।
डैरनडब्ल्यू

4
@DarenW - लेकिन इतना कार्य / प्रक्रिया / तरीके करते हैं। और बाद में कोड को संशोधित करने का अतिरिक्त लाभ होता है, जिससे इसे समझना आसान हो जाता है
स्टीफन सी

3
इसका एक अन्य लाभ यह है कि फ़ंक्शन InitializeBoardया InitializePlayerमॉड्यूल / क्लास ब्राउज़र सूची में अधिकांश IDEs जैसे कार्य या दिखाई देंगे जबकि टिप्पणियां नहीं होंगी। आसान नेविगेशन।
स्टीव फॉल्स

13

मेरे पास हर व़क्त करने को यही काम है। दोनों को चिह्नित करने के लिए कि कोड क्या कर रहा है, और शायद अधिक महत्वपूर्ण बात, जैसा कि आपने कहा, कोड का एक हिस्सा स्कैन करना और ढूंढना आसान बनाने के लिए। कभी-कभी, भी, मैं टिप्पणियों में एक सम्मिलित प्रक्रिया लिखूंगा, और टिप्पणियों के तहत कोड को 'भर दूंगा'।


7
+1 - स्पष्टता एक अच्छी बात है। मैं अनुमोदित उत्तर से असहमत हूं क्योंकि यह एक कोड गंध है। यदि यह स्पष्टता जोड़ता है - यह करो।
जल्दी_अगले

2
यदि यह OAOO का उल्लंघन करता है, तो ऐसा न करें। यह निरर्थक है, और कोड के साथ सिंक से बाहर निकल जाता है जो इसे दस्तावेज़ करता है। कोड को एक फंक्शन में रखें और फंक्शन को नाम दें कि यह क्या करता है। आधुनिक आईडीई ने फ़ंक्शन नाम को बदलना और सभी संदर्भों को अपडेट करना आसान बना दिया है। इस तरह सभी उदाहरण आज तक बने हुए हैं।
स्कॉट व्हिटलॉक

3
मुझ से +1। बड़ी कोड फ़ाइलों में, मुझे तार्किक अनुभागों को अलग करने वाले व्हाट्सएप से अधिक होना पसंद है। हां, मुझे लगता है कि अगर आपका कार्य छोटा है, तो आपको इसे विभाजित करने की आवश्यकता है, लेकिन मुझे यह पढ़ना बहुत आसान लगता है कि क्या भागों को टिप्पणियों द्वारा अलग किया गया है।
एंथनी

6

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


4

मैं इन चीजों को कोड को स्पष्ट करने या न करने के तरीके के रूप में देखता हूं। आप फ़ाइल प्रत्येक भाग का क्या है में तरीकों के आधार पर बता सकते हैं तो कोई ज़रूरत नहीं आप फिर भी अगर कोई है तो यह उपयोगी हो सकता है एकाधिक अनुभागों के लिए। शायद जब कोई कोड फ़ाइल बहुत बड़ी हो जाती है तो उसे तोड़ना पड़ता है जिससे ऐसी टिप्पणियों की आवश्यकता कम हो सकती है।

मैं कहूंगा कि अगर किसी टीम के भीतर काम करना एक मानक के साथ आता है तो आप सभी कम से कम कोडिंग कर रहे हैं और उसी तरह से टिप्पणी कर रहे हैं ताकि कोड देखना आसान हो जाए।


3

मैं ऐसा इसलिए कर रहा हूं क्योंकि मैं अक्सर खुद के इरादे से संवाद कर रहा हूं, या अनिवार्य रूप से "डेटा क्लीनिंग यहां शुरू होती है" जैसी चीजों के लिए एक सुविधाजनक बुकमार्क में डाल रहा हूं। आमतौर पर उस शीर्षक के तहत मैं क्या कर रहा हूँ और क्यों के तर्क के बारे में एक संक्षिप्त सा है।

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

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


व्यावसायिक उद्देश्य / उच्च-स्तरीय उद्देश्य बताते हुए टिप्पणियाँ बहुत सार्थक हैं। वे पुष्टि और समर्थन समझ को सक्षम करते हैं। यूनिट परीक्षणों को निरर्थक होने का दावा किया जा सकता है, भी - मैं सुझाव दूंगा कि कोडिंग और समझ कोड कम से कम यह परीक्षण करने जितना महत्वपूर्ण है।
थॉमस डब्ल्यू

2

मुझे लगता है कि यह उन स्थितियों में उपयोगी है जहां आपके पास दर्जनों कार्यों के साथ विशाल स्रोत फाइलें हैं और आप उन्हें उसी तरह से विखंडित रूप से व्यवस्थित कर सकते हैं। मैं यह नहीं कह रहा हूं कि मुझे छोटे, अधिक केंद्रित स्रोत फ़ाइलों की तुलना में बेहतर है ...

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.