स्रोत कोड टिप्पणी स्टाइलिंग युक्तियाँ और सर्वोत्तम अभ्यास

जिन डेवलपर्स ने बड़ी परियोजनाओं पर किसी भी समय बिताया है, वे कोड टिप्पणियों के महत्व को समझते हैं। जब आप एक ही एप्लिकेशन में कई सुविधाएं बना रहे होते हैं, तो चीजें जटिल हो जाती हैं। फ़ंक्शंस, वैरिएबल रेफ़रेंस, रिटर्न वैल्यूज़, पैरामीटर्स सहित बहुत सारे डेटा बिट्स हैं ... आपको कैसे बनाए रखने की उम्मीद है?

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

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

टिप्पणी शैलियाँ: एक अवलोकन

यह ध्यान दिया जाना चाहिए कि प्रस्तुत ये विचार केवल हैं दिशा निर्देशों क्लीनर की टिप्पणियों की ओर। अलग-अलग प्रोग्रामिंग लैंग्वेज आपके डॉक्यूमेंटेशन को सेटअप करने के दिशा-निर्देशों या विशिष्टताओं को निर्धारित नहीं करती हैं.

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

इनलाइन टिप्पणी

व्यावहारिक रूप से हर एक प्रोग्रामिंग भाषा प्रदान करता है इनलाइन टिप्पणियाँ. ये एकल-पंक्ति सामग्री तक सीमित हैं और केवल एक निश्चित बिंदु के बाद पाठ की टिप्पणी करते हैं। तो उदाहरण के लिए C / C ++ में आप इनलाइन टिप्पणी शुरू करते हैं:

// वेरिएबल लिस्टिंग वर्जन myvar = 1;… 

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

अगर (callAjax ($ params)) // सफलतापूर्वक उपयोगकर्ता मापदंडों के साथ callAjax चलाएं ... कोड

सभी कोड के ऊपर नोटिस को ब्रैकेट खोलने के बाद एक नई लाइन पर होना चाहिए। अन्यथा यह सब एक ही टिप्पणी लाइन पर पकड़ा जाएगा! ओवरबोर्ड जाने से बचें चूँकि आपको आम तौर पर अपने पृष्ठ के नीचे एकल-लाइन टिप्पणियों को देखने की आवश्यकता नहीं है, लेकिन विशेष रूप से आपके कोड में जंक्शनों को भ्रमित करने के लिए, अंतिम समय में इन्हें छोड़ना बहुत आसान है.

वर्णनात्मक ब्लॉक

जब आपको एक बड़े स्पष्टीकरण को शामिल करने की आवश्यकता होती है तो आमतौर पर एक एकल लाइनर चाल नहीं चलेगा। प्रोग्रामिंग के हर क्षेत्र के बारे में पूर्व-स्वरूपित टिप्पणी टेम्पलेट का उपयोग किया जाता है. वर्णनात्मक ब्लॉक फ़ंक्शंस और लाइब्रेरी फ़ाइलों के आसपास सबसे विशेष रूप से देखा जाता है। जब भी आप एक नया फंक्शन सेटअप करते हैं तो यह अच्छा अभ्यास है घोषणा के ऊपर एक वर्णनात्मक ब्लॉक जोड़ें.

/ ** * @desc एक संदेश प्रदर्शित करने के लिए एक मोडल विंडो खोलता है * @param string $ msg - प्रदर्शित होने वाला संदेश * @return bool - सफलता या विफलता * / फ़ंक्शन modalPopup ($ msg) … 

ऊपर एक वर्णनात्मक फ़ंक्शन टिप्पणी का एक सरल उदाहरण है। मैंने जावास्क्रिप्ट में संभवतः फ़ंक्शन को लिखा है modalPopup जो एकल पैरामीटर लेता है। ऊपर की टिप्पणियों में मैंने phpDocumentor के समान एक सिंटैक्स का उपयोग किया है जहां प्रत्येक पंक्ति a से पहले है @ एक चयनित कुंजी के बाद प्रतीक। ये आपके कोड को किसी भी तरह से प्रभावित नहीं करने वाले हैं, इसलिए आप लिख सकते हैं @विवरण के बजाय @desc कोई परिवर्तन नहीं.

इन छोटी चाबियों को वास्तव में कहा जाता है टिप्पणी टैग जो वेबसाइट पर भारी मात्रा में प्रलेखित हैं। बेझिझक अपना बनाइए और इनका उपयोग अपने पूरे कोड के अनुसार कीजिए। मुझे लगता है कि वे सब कुछ बहने में मदद करते हैं मैं एक नज़र में महत्वपूर्ण जानकारी की जांच कर सकता हूं. आपको यह भी ध्यान देना चाहिए कि मैंने इसका उपयोग किया है / * * / ब्लॉक-शैली टिप्पणी प्रारूप। यह सब कुछ रखेगा बहुत क्लीनर प्रत्येक पंक्ति में एक डबल स्लैश शुरुआत जोड़ने से.

समूह / कक्षा टिप्पणियाँ

कार्यों और छोरों पर टिप्पणी करने के अलावा, ब्लॉक क्षेत्रों का अक्सर उपयोग नहीं किया जाता है। जहां आपको वास्तव में मजबूत की जरूरत है टिप्पणियाँ ब्लॉक करें आपके बैकएंड डॉक्यूमेंट्स या लाइब्रेरी फाइल्स के हेड पर हैं। ऑल-आउट जाना और अपनी वेबसाइट में हर फ़ाइल के लिए ठोस दस्तावेज़ लिखना आसान है - हम इस अभ्यास को कई सीएमएस जैसे वर्डप्रेस में देख सकते हैं.

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

/ ** * @desc यह वर्ग उपयोगकर्ता इंटरैक्शन के लिए फ़ंक्शंस करेगा। उदाहरणों में user_pass (), user_username (), user_age (), user_regdate () * @author जेक रोशेल्यू [email protected] * @required settings.php * / शामिल हैं। सार वर्ग myWebClass  

आप देख सकते हैं कि मैंने नकली के लिए सिर्फ एक छोटा सा नमूना वर्ग उपयोग किया है myWebClass कोड। मैंने कुछ मेटा जानकारी जोड़ी है संपर्क के लिए मेरे नाम और ईमेल पते के साथ. जब डेवलपर्स ओपन सोर्स कोड लिख रहे हैं तो यह आम तौर पर अच्छा अभ्यास होता है, ताकि अन्य आपसे समर्थन के लिए संपर्क कर सकें। बड़ी विकास टीमों में काम करते समय यह भी एक ठोस तरीका है.

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

फ्रंट-एंड कोड टिप्पणी

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

जावास्क्रिप्ट जावा, पीएचपी और सी / सी के समान टिप्पणी करने की अधिक पारंपरिक विधि का अनुसरण करता है++. CSS केवल स्लैश और तारांकन द्वारा चित्रित ब्लॉक-शैली टिप्पणियों का उपयोग करता है. आपको याद रखना चाहिए कि आपके आगंतुकों के लिए टिप्पणियाँ खुले तौर पर प्रदर्शित की जाएंगी, क्योंकि न तो CSS और न ही JS को सर्वर-साइड पार्स किया गया है, लेकिन इनमें से कोई भी तरीका आपके कोड में जानकारीपूर्ण tidbits को वापस जाने के लिए बहुत अच्छा काम करता है.

विशेष रूप से CSS फ़ाइलों को तोड़ना एक काम हो सकता है। Internet Explorer या Safari के लिए कोई फ़िक्स समझाने के लिए इनलाइन टिप्पणी छोड़ने से हम सभी परिचित हैं। लेकिन मेरा मानना ​​है कि CSS टिप्पणी का उपयोग jQuery के स्तर पर किया जा सकता है और PHP उनका उपयोग करता है। कोड टिप्पणी के लिए कुछ विस्तृत सुझावों को छूने से पहले शैली समूह बनाने में देरी करते हैं.

सीएसएस शैली समूह

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

जब आप CSS को संपादित करने के लिए वापस जा रहे हैं तो मैं आसानी से पा सकता हूं कि मुझे कुछ सेकंड में क्या चाहिए। जिस तरह से आप समूह शैलियों को चुनते हैं वह पूरी तरह से आपके ऊपर है, और यही इस प्रणाली की सुंदरता है। मुझे कुछ पूर्व निर्धारित मानक मिले हैं, जिन्हें मैंने नीचे उल्लिखित किया है:

• @resets - डिफ़ॉल्ट ब्राउज़र मार्जिन, पैडिंग, फोंट, रंग आदि को दूर ले जाना.
• @fonts - पैराग्राफ, हेडिंग, ब्लॉकक्वाट्स, लिंक, कोड
• @navigation - मुख्य कोर वेबसाइट नेविगेशन लिंक
• @layout - आवरण, कंटेनर, साइडबार
• @header & @footer - ये आपके डिज़ाइन के आधार पर भिन्न हो सकते हैं। संभावित शैलियों में लिंक और अनऑर्डर किए गए सूचियां, पाद लेख कॉलम, शीर्षक, उप-नौसेना शामिल हैं

स्टाइलशीट को ग्रुप करते समय मैंने पाया है टैगिंग प्रणाली बहुत मदद कर सकता है। हालांकि PHP या जावास्क्रिप्ट के विपरीत मैं एक एकल का उपयोग करता हूं @group किसी श्रेणी या कीवर्ड के बाद टैग। मैंने नीचे 2 उदाहरणों को शामिल किया है ताकि आप मेरे लिए एक अर्थ प्राप्त कर सकें.

/ ** @ समूह पाद लेख * / # भूत शैलचित्र

/ ** @ समूह पाद, छोटे फ़ॉन्ट, कॉलम, बाहरी लिंक ** / 

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

बेहतर टिप्पणी स्टाइल के लिए 4 टिप्स

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

1. सब कुछ पढ़ने योग्य

कभी-कभी डेवलपर्स के रूप में हम यह भूल जाते हैं हम मनुष्यों को पढ़ने के लिए टिप्पणियाँ लिख रहे हैं. हमारे द्वारा समझी जाने वाली सभी प्रोग्रामिंग भाषाएं मशीनों के लिए बनाई गई हैं, इसलिए इसे सादे लिखित पाठ में बदलना थकाऊ हो सकता है। यह ध्यान रखना महत्वपूर्ण है कि हम यहां कॉलेज स्तर के शोध पत्र लिखने के लिए नहीं हैं, लेकिन सिर्फ सुझाव छोड़ रहे हैं!

फ़ंक्शन getTheMail () // कोड यहां ई-मेल / * रन कोड का निर्माण करेगा यदि हमारा कस्टम sendMyMail () फ़ंक्शन कॉल सही लगता है sendMyMail () /libs/mailer.class.php में देखें कि उपयोगकर्ता सभी फ़ील्ड भरता है या नहीं और संदेश भेजा है! * (अगर (sendMyMail ()) वापसी सच; // सच रखें और ऑनस्क्रीन सफलता प्रदर्शित करें

यहां तक ​​कि सिर्फ दो शब्द हैं कुछ नहीं से बेहतर. जब आप भविष्य में परियोजनाओं को संपादित करने और काम करने के लिए वापस जाते हैं तो अक्सर आश्चर्य होता है कि आप कितना भूल जाएंगे। चूंकि आप हर दिन एक ही चर और फ़ंक्शन नाम नहीं देख रहे हैं, इसलिए आप धीरे-धीरे अपने कोड के अधिकांश भाग को भूल जाते हैं। इस प्रकार आप कर सकते हैं बहुत सारी टिप्पणियों को कभी न छोड़ें! लेकिन आप बहुत सी बुरी टिप्पणियाँ छोड़ सकते हैं.

अंगूठे के एक सामान्य नियम के रूप में, लिखने से पहले रुकने और प्रतिबिंबित करने के लिए कुछ समय लें. अपने आप से पूछो क्या कार्यक्रम के बारे में सबसे भ्रमित है तथा आप इसे कैसे समझा सकते हैं “डमी” भाषा? विचार भी करें आप जैसे हैं वैसे ही कोड लिख रहे हैं.

जब आप कस्टम-बिल्ट (या 3 पार्टी) फ़ंक्शन के उद्देश्य को भूल जाते हैं, तो कुछ सबसे अधिक भ्रमित करने वाली त्रुटियां पॉप अप होती हैं. कुछ अन्य फ़ाइलों पर वापस जाने के लिए एक टिप्पणी निशान छोड़ दें अगर इससे आपको कार्यक्षमता याद रखने में आसानी होगी.

2. कुछ जगह को अलग करें!

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

$ dir1 = "/ घर /"; // सेट मुख्य घर निर्देशिका $ myCurrentDir = getCurDirr (); // वर्तमान उपयोगकर्ता निर्देशिका $ userVar = $ get_username () सेट करें; // वर्तमान उपयोगकर्ता का उपयोगकर्ता नाम

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

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

$ (दस्तावेज़)। पहले से ही (फ़ंक्शन () $ ('उप')। छिपाने (); // पगेलोड पर उप-नेविगेशन छिपाएं / ** एक एंकर के अंदर एक क्लिक की घटना के लिए जाँच करें। यह div डिफ़ॉल्ट लिंक को रोकती है। कार्रवाई इसलिए पृष्ठ क्लिक पर परिवर्तित नहीं होता है। इसके बाद .itm के मूल तत्व का उपयोग करें। खुली / बंद ** / $ ('itm a') को टॉगल करने के लिए अगली .sub सूची का उपयोग करें। लाइव ('क्लिक', फ़ंक्शन (e) ) e.preventDefault (); $ (यह) .परेंट () अगला ('सब')। स्लाइडटॉगल ('फास्ट');););

यह एक छोटा सा jQuery कोड है जो उप-मेनू स्लाइडिंग नेविगेशन को लक्षित करता है। पहली टिप्पणी यह ​​बताने के लिए इनलाइन है कि हम सभी को क्यों छिपा रहे हैं .उप कक्षाएं। लाइव क्लिक इवेंट हैंडलर के ऊपर मैंने एक ब्लॉक कमेंट का उपयोग किया है और सभी लेखन को एक ही बिंदु पर प्रेरित किया. यह चीजों को रन-ऑन पैराग्राफ के बजाय प्राइटर बनाता है - विशेष रूप से आपकी टिप्पणियों को पढ़ने वाले अन्य लोगों के लिए.

3. टिप्पणी करते समय कोडिंग

उचित रिक्ति के साथ यह सबसे अच्छी आदतों में से एक हो सकता है। हर काम और दस्तावेज़ के हर टुकड़े के बाद कोई भी अपने कार्यक्रम से पीछे नहीं हटना चाहता। हम में से अधिकांश भी भ्रमित क्षेत्रों में वापस जाने और दस्तावेज करना नहीं चाहते हैं! यह वास्तव में बहुत काम लेता है.

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

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

4. छोटी गाड़ी त्रुटियों से निपटना

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

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

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

निष्कर्ष

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

यदि आपके पास स्पष्ट कोड टिप्पणी के लिए सुझाव हैं, तो हमें नीचे चर्चा क्षेत्र में बताएं!