मुझे अपनी कक्षा के प्रलेखन हेडर में क्या शामिल करना चाहिए


15

मैं अपने एंटिटी, बिजनेस लॉजिक और डेटा एक्सेस क्लासेस के लिए सूचनात्मक वर्ग प्रलेखन प्रारूप की तलाश कर रहा हूं।

मुझे यहाँ से दो प्रारूप मिले

प्रारूप 1

///-----------------------------------------------------------------
///   Namespace:      <Class Namespace>
///   Class:          <Class Name>
///   Description:    <Description>
///   Author:         <Author>                    Date: <DateTime>
///   Notes:          <Notes>
///   Revision History:
///   Name:           Date:        Description:
///-----------------------------------------------------------------

प्रारूप 2

// ===============================
// AUTHOR     :
// CREATE DATE     :
// PURPOSE     :
// SPECIAL NOTES:
// ===============================
// Change History:
//
//==================================

मुझे लगता है कि निम्नलिखित मूल तत्व हैं

  • लेखक
  • रचना तिथि
  • विवरण
  • संशोधन इतिहास

वैसे भी नाम और वर्ग का नाम वहाँ होगा।

कृपया मुझे अपने विचारों से अवगत कराएं, कौन सा प्रारूप अनुशंसित है और क्या संशोधन इतिहास लिखने का कोई मानक तरीका है?


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

5
लेखक और निर्माण की तिथि भी स्रोत नियंत्रण द्वारा नियंत्रित की जाती है। आपको केवल एक विवरण की आवश्यकता है।
माइक सेमोर

जवाबों:


27

आपके द्वारा सुझाई गई अधिकांश जानकारी स्रोत रिपॉजिटरी में मिलेगी।

केवल एक चीज जो आपको वास्तव में चाहिए, वह उद्देश्य अनुभाग है, जो कहता है कि कक्षा किस लिए है।

हर बार जब आप दूसरी जानकारी जानना चाहते हैं तो क्या रिपॉजिटरी में देखना थकाऊ होगा? मैं कहता हूँ नहीं। मूल लेखक कौन था, आप कितनी बार परवाह करते हैं? या जब पहली बार फ़ाइल बनाई गई थी? प्लगइन्स (जैसे कि विज़ुअल स्टूडियो के लिए अनक एसवीएन) अक्सर आपको अपनी वर्तमान फ़ाइल के भीतर राइट क्लिक करने और फ़ाइल के लिए रीपोस्टॉइर लॉग देखने की अनुमति देता है, इसलिए यह वास्तव में इस जानकारी को देखने के लिए बहुत परेशानी की बात नहीं है।

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


14

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

जेफ एटवुड का यह लेख पढ़ें - बिना किसी टिप्पणी के कोडिंग


अगर मैं कर सकता तो मैं इस उत्तर को +100 वोट देता।
क्रिस होम्स

5

मैं दस्तावेज़ बनाने के लिए मानक टैग का उपयोग करता हूं। न कुछ ज्यादा, न कुछ कम। यहाँ देखें

मैंने कभी ऐसी जानकारी नहीं डाली जो कक्षा से संबंधित न हो। लेखक, डेटा, संशोधन एक संस्करण नियंत्रण प्रणाली पर संग्रहीत करने के लिए डेटा हैं।

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


3

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


@karianna - तो आप क्लास कंट्रोल के स्रोत विवरण रिपॉजिटरी को छोड़कर सब कुछ छोड़ने का सुझाव दे रहे हैं; लेकिन, क्या यह हर बार रिपॉजिटरी लॉग से देखने के लिए थकाऊ होगा। और क्या होगा अगर मैं प्रलेखन फ़ाइल (जैसे .chm या सैंडकास्टल) बनाना चाहता हूं?
कोडरहॉक

@ कैंडी आपको अपने कोड कमेंट हेडर में कुछ कीवर्ड डालने में सक्षम होना चाहिए जो आपके स्रोत नियंत्रण रिपॉजिटरी आपके द्वारा चेक किए गए प्रत्येक को अपडेट करेगा। यह इस बात पर निर्भर करता है कि आप किस भाषा में कोडिंग कर रहे हैं और आप किस सोर्स कंट्रोल रेपो का उपयोग कर रहे हैं। तुम क्या प्रयोग कर रहे हो? :)
मार्टिज़न वर्बर्ग

@ करियाना - मैं तोड़फोड़ का उपयोग कर रहा हूं; उम्मीद है कि छोटी तकनीक / प्रोग्रामिंग पर चर्चा करना बंद नहीं होगा! :-) कृपया मुझे बताएं कि क्या मुझे एसओ में एक प्रश्न पोस्ट करने की आवश्यकता है, जिसमें लॉग टिप्पणी को विशेष वर्ग में कैसे मर्ज किया जाए? :-)
कोडरवाक

आप $ Id: $ और $ URL का उपयोग कर सकते हैं: $,: वैकल्पिक हो सकता है, मैं भूल गया। उम्मीद है कि SO अधिपति हमारी निन्दा के लिए हमें नहीं
मारेंगे

3

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

अगर मुझे यह पता लगाने के लिए आपका "विवरण" पढ़ना है कि आपकी कक्षा क्या कर रही है, तो (क) आपके नाम ने इसे खराब तरीके से या (b) आपने एक बुरा वर्ग लिखा है जो बहुत अधिक कर रहा है (SRP)।


2

मैं अपने हेडर टेम्प्लेट को बदलने के साथ खेल रहा हूँ, क्योंकि अन्य लोग बताते हैं, इस जानकारी का बहुत कुछ भंडार में पाया जा सकता है और अब तक जिन बड़े क्षेत्रों को मैं देख रहा हूँ, वे निम्नलिखित हैं:

  • विवरण - कोड द्वारा क्या किया जा रहा है।
  • नोट्स - कोड के बारे में कुछ भी जानने की आवश्यकता है जो कोड में टिप्पणियों से आसानी से प्राप्त नहीं होता है।
  • संदर्भ - कोई भी संदर्भ जो कोड पर निर्भर है, जो स्पष्ट नहीं है, हालांकि includeया इसी तरह के बयानों का उपयोग किया जाता है।

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


1

अब तक पढ़े गए अधिकांश अन्य उत्तरों में मैंने माना है कि केवल एक रिपॉजिटरी है जो हमेशा उपलब्ध है

चूंकि सोर्सकोड रिपॉजिटरी से कनेक्शन को ढीला कर सकता है (अर्थात यदि कॉपी किया गया है) तो मेरा क्लास डॉक्यूमेंटेशन इस प्रकार है:

  • class documentation header (= फ़ाइल की शुरुआत में टिप्पणी ब्लॉक) में केवल आवश्यक कानूनी जानकारी शामिल है (यानी gpl-लाइसेंस के तहत xyz द्वारा कॉपीराइट)
  • वह सब कुछ जो एक डेवलपर जो कक्षा का उपयोग करता है, को पता होना चाहिए कि उसे क्लास-जावा-डॉक-टिप्पणियों (या इसके समकक्ष .net) में जाना चाहिए ताकि आधुनिक आइड-एस इस जानकारी को टूलटिप जानकारी इन्स सोर्सकोड के रूप में दिखा सके जो कक्षा का उपयोग करता है।

आप बगफिक्स या फीचर-रिक्वेस्ट के लिए भी टिकटनुमा जोड़ सकते हैं ताकि आपके पास कुछ सुराग हो सकता है जहां / कब / क्यों वर्ग बनाया गया था (यदि आप पर्याप्त भाग्यशाली हैं कि आप कुछ वर्षों के बाद भी टिकट का उपयोग कर सकते हैं)।

जब मधुमक्खी से पुराने बंद-स्रोत विरासत की समस्याओं को ठीक करने के लिए कहा जाता है तो टिकट संख्याएं मेरे लिए कोड की मूल आवश्यकताओं को समझने के लिए काफी मूल्यवान हैं।

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