2010-08-25 20 views
36

मेरे पास एकाधिक फाइलों वाला एक सी प्रोग्राम है, इसलिए उदाहरण के लिए, stuff.c है जो फ़ंक्शन प्रोटोटाइप के साथ कुछ फ़ंक्शंस और stuff.h लागू करता है।सी में कार्यों को दस्तावेज करने के लिए कहां?

टिप्पणियों में कार्यों को दस्तावेज करने के बारे में मुझे कैसे जाना चाहिए?

क्या मेरे पास हेडर फ़ाइल में सभी दस्तावेज़ हैं, .c फ़ाइल में सभी दस्तावेज़, या दोनों के लिए दस्तावेज़ डुप्लिकेट करना चाहिए? मुझे बाद का दृष्टिकोण पसंद है, लेकिन फिर मैं उन समस्याओं में भाग लेता हूं जहां मैं उनमें से किसी एक पर दस्तावेज़ अपडेट करूँगा, न कि दूसरे (आमतौर पर वह जहां मैं पहला संशोधन करता हूं, यानी यदि मैं पहले हेडर फ़ाइल को संशोधित करता हूं, तो इसकी टिप्पणियां इसे प्रतिबिंबित करेगा, लेकिन अगर मैं कार्यान्वयन को अद्यतन करता हूं, तो केवल वे टिप्पणियां बदल जाएंगी)।

उत्तर

60
  • जानकारी दें कि फ़ंक्शंस का उपयोग करने वाले लोगों को हेडर में जानने की आवश्यकता है।

  • जानकारी को रखें कि कार्यों के रखरखावकर्ताओं को स्रोत कोड में जानने की आवश्यकता है।

+2

+1: अच्छी तरह से सारांशित। –

4

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

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

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

10

आपको doxygen जैसे टूल का उपयोग करना चाहिए, इसलिए दस्तावेज़ आपके स्रोत कोड में विशेष रूप से तैयार की गई टिप्पणियों द्वारा उत्पन्न होता है।

2

आप बस Doxygen .. इसके अलावा, आप this answer देख सकते हैं इस्तेमाल कर सकते हैं।

6

मैं इस पर आगे और आगे चला गया और अंततः मैं हेडर फाइलों में प्रलेखन पर बस गया। सी/सी ++ में एपीआई के विशाल बहुमत के लिए आपके पास मूल हेडर फ़ाइल तक पहुंच है और इसलिए [1] के भीतर मौजूद सभी टिप्पणियां हैं। यहां टिप्पणियां डालने से अवसर डेवलपर्स उन्हें देख सकेंगे।

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

[1] इस नियम के अपवादों में कुछ COM पुस्तकालयों से जेनरेट की गई हेडर फाइलें शामिल हैं।

2

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

1

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

दस्तावेज़ों का "सुंदर" संस्करण बनाने के लिए Doxygen जैसे कुछ का उपयोग करें।

7

मैं गूगल सी ++ Style Guide.

जो कहते हैं अनुसरण करना: यह है कि वर्णन

समारोह घोषणा

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

कार्यशील परिभाषाएँ

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

    नोट करें कि आपको टिप्पणियों को 0hघोषणा के साथ दिए गए टिप्पणियों को दोहराना नहीं चाहिए, कहीं भी .h फ़ाइल या में। संक्षेप में कार्य करने के लिए ठीक है, लेकिन टिप्पणियों का ध्यान होना चाहिए कि यह कैसा होता है।

0

हेडर बनाम कार्यान्वयन फ़ाइल में टिप्पणियों को इस बात को दर्शाता है कि दोनों का उपयोग कैसे किया जाता है।

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

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

1

यह वास्तव में सरल है जब आप इसके बारे में सोचते हैं।

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

नियम के रूप में, कार्यान्वयन विवरण API उपयोगकर्ताओं से छिपा होना चाहिए। इसमें कार्यान्वयन के दस्तावेज शामिल हैं (सिवाय इसके कि यह उपयोग को प्रभावित कर सकता है जैसे समय जटिलता आदि)। इस प्रकार कार्यान्वयन दस्तावेज कार्यान्वयन फ़ाइल में जाना चाहिए।

कभी भी कई स्थानों पर दस्तावेज़ों को डुप्लिकेट न करें। यह अनजान होगा और जैसे ही किसी को इसे बदलना होगा, लगभग सिंक हो जाएगा।

1

मैंने एक साधारण स्क्रिप्ट लिखी है जो एक टेम्पलेट हेडर-फ़ाइल इनपुट के रूप में नहीं लेती है जिसमें कोई फंक्शन घोषणा नहीं होती है और टिप्पणी किए गए कार्यों के साथ एक स्रोत-कोड फ़ाइल होती है। स्क्रिप्ट स्रोत कोड फ़ाइल से फ़ंक्शन परिभाषा से पहले टिप्पणी निकालती है और इसे आउटपुट हेडर-फ़ाइल में संबंधित फ़ंक्शन घोषणा लिखती है। यह सुनिश्चित करता है कि 1) केवल एक ही स्थान है जहां फ़ंक्शन कमेंट्री को लिखा जाना आवश्यक है; और 2) हेडर-फ़ाइल में प्रलेखन और स्रोत कोड फ़ाइल हमेशा सिंक में रहती है। फ़ंक्शन के कार्यान्वयन पर टिप्पणी को फ़ंक्शन के शरीर में रखा जाता है और निकाला नहीं जाता है।

संबंधित मुद्दे