आप कोड के लेखकों पर नज़र कैसे रखेंगे? [बन्द है]

Question

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

मैं आमतौर पर बस जाता हूं

@author garbagecollector
@company garbage inc.

Comments

आपका कोड बदलने वाले व्यक्ति ने अपना नाम कहां रखा है?

— जेफो

@ जेफ कहां और कैसे दिखता है।

— डस्टप्रोग्रामग्राम 15

यह करने के लिए कोई मतलब नहीं है। आप ऐसा क्यों करना चाहते हो?

— कोडार्ट

Answer 1

पूरी तरह से निश्चित नहीं है कि आप क्या पूछ रहे हैं, हालांकि मैं बहुत सख्त शैली का उपयोग करता हूं:

;==========================================
; Title:  Author Style Sample
; Author: Darknite
; Date:   7 Jan 2011
;==========================================

शैली विधानसभा प्रोग्रामर से प्रेरित है।

मैंने इसे उन पृष्ठों के शीर्ष पर रखा है जिनकी मुझे "लेखक" को आवश्यकता है, भले ही यह एक वर्ग, पाठ फ़ाइल, या SQL संग्रहीत कार्यविधि आदि हो।

Comments

यह मैं क्या देख रहा हूँ की तर्ज पर है।

— डस्टप्रोग्रामग्राम

-1 यह (जो एक बहुत बढ़ता है , तो अद्यतन (दोनों यह और विभिन्न लोगों द्वारा कोड में परिवर्तन) को प्रभावी ढंग संस्करण नियंत्रण द्वारा बदल दिया गया है।

— माइकल Durrant

@MichaelDurrant आप अपने कोष्ठक को बंद करना भूल गए;) वैसे भी शांत। मुझे पेंगुइन पसंद है।

— अंधेरी

@Giorgio वास्तव में नहीं ... फ़ाइल में छोड़े गए मूल लेखक के कोड की एक भी पंक्ति नहीं हो सकती है। यह व्यर्थ है।

— विल्बर्ट

@Wilbert: बेशक, यह टीम की नीति पर भी निर्भर करता है: साझा कोड स्वामित्व के साथ, यह किसी फ़ाइल के लेखक पर नज़र रखने के लिए व्यर्थ हो सकता है। व्यक्तिगत कोड स्वामित्व के साथ यह जानना महत्वपूर्ण है कि कौन सी फ़ाइलों के लिए जिम्मेदार है।

— जियोर्जियो

Answer 2

आप क्यों? यह संस्करण प्रणाली और "दोष" का काम है :)

Comments

संस्करण नियंत्रण ftw।

— पॉल नाथन

यह उस तरह से करने के लिए और भी अधिक समझ में आता है यदि आप इसे संस्करण नियंत्रण प्रणाली (वीसीएस) के बजाय स्रोत कोड प्रबंधन (एससीएम) के रूप में सोचते हैं।

— पीटर आइजेंट्रुत

छोटी सीमा, कॉस्मेटिक परिवर्तन (इंडेंटेशन, आदि ...) लाइन के लेखक को बदलते हैं ...

— मैथ्यू एम।

@ मैथ्यू: अच्छा एससीएम दिखा सकता है कि किसने समय के साथ क्या बदलाव किए, न कि इसे छूने के लिए आखिरी। मैं यह भी तर्क दे सकता हूं कि कॉस्मेटिक बदलाव भी बदलाव हैं।

— सकल भाव

यह उत्तर 8 वर्ष से अधिक पुराना है, और किसी ने इसके प्रतिबंधों पर ध्यान नहीं दिया? यह केवल तभी लागू होता है जब स्रोत कोड अपने पूरे जीवन काल (या ठीक से माइग्रेट) पर एक VCS में रहता है! हालाँकि, बहुत सारे ओपन सोर्स कोड समय-समय पर अलग-अलग वातावरणों के बीच ट्रांसफर किए जाते हैं, इसलिए लेखक की जानकारी को पास नहीं किया जा सकता है यदि इसे सीधे सोर्स कोड में नहीं लिखा गया है।

— डॉक्टर ब्राउन

Answer 3

हम अपनी कंपनी में संलेखन नहीं करते हैं। इसके बजाय, हम अपने संस्करण को नियंत्रित करने देते हैं।

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

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

Answer 4

मैं ऐसा बिल्कुल नहीं करता। मुझे लगता है कि काम के दौरान हमारे पास कुछ टेम्पलेट हैं जो कंपनी के नाम और उस व्यक्ति के उपयोगकर्ता नाम के साथ फाइलों में सम्मिलित हो जाते हैं, जिन्होंने पिछली बार फाइल को संशोधित किया था, लेकिन मैंने उस पर कभी ध्यान नहीं दिया।

सामान्य तौर पर, मुझे नहीं लगता कि यह वास्तव में मायने रखता है कि आप इसे कैसे करते हैं। यदि आप अपनी फ़ाइलों को लेखक-मुद्रांकित करना चाहते हैं, तो बस एक सुसंगत शैली चुनें और उसके साथ जाएं।

Answer 5

जावा समुदाय में जावाडॉक बहुत मानक है:

http://download.oracle.com/javase/1.3/docs/tooldocs/win32/javadoc.html#@author

@author नाम-पाठ

" डॉटर" का उपयोग किए जाने पर उत्पन्न डॉक्स के लिए निर्दिष्ट नाम-पाठ के साथ "लेखक" प्रविष्टि जोड़ता है। एक डॉक टिप्पणी में कई @authorटैग हो सकते हैं । आप प्रति @authorटैग एक नाम या प्रति टैग कई नाम निर्दिष्ट कर सकते हैं । पूर्व मामले में, जावाडॉक नामों के बीच एक अल्पविराम (,) और स्थान सम्मिलित करता है। बाद के मामले में, पूरे पाठ को केवल जनरेटेड दस्तावेज़ में कॉपी किया जाता है, बिना पार्स किए बिना। इसलिए, यदि आप स्थानीय नाम विभाजक को अल्पविराम के अलावा चाहते हैं तो प्रति पंक्ति कई नामों का उपयोग करें।

Answer 6

मुझे लगता है कि संस्करण नियंत्रण प्रणाली के लिए यह सबसे अच्छा बचा है।

Answer 7

मुझे जीआईटी में दोष सुविधा पसंद है । आप देख सकते हैं कि कोड के प्रत्येक टुकड़े / पंक्ति को किसने लिखा है। सिर्फ एक फाइल नहीं।

Comments

अन्य वीसीएस में एक ही चीज होती है (यद्यपि अक्सर "दोष" नहीं कहा जाता है)।

— रिचर्ड

मैं इसे -1 चाहता हूं क्योंकि यह जीआईटी विशिष्ट है। ओपी ने कभी जीआईटी का उल्लेख नहीं किया। लेकिन अफसोस, मेरे पास बहुत कुछ नहीं है।

— थॉमस ईडिंग

Answer 8

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

ये सवाल संस्करण नियंत्रण प्रणाली के लिए बेहतर हैं।

लेकिन मैं पूरी तरह से लेखकों की सूची के खिलाफ नहीं हूं। पूरे प्रोजेक्ट के लिए लेखकों की सूची रखना सही अर्थ है। यदि यह एकल-फ़ाइल-प्रोजेक्ट है, तो निश्चित रूप से, इसे उसी फ़ाइल के अंदर रखें। यदि यह बड़ा प्रोजेक्ट है तो इसे README या अपने शीर्ष स्तर स्रोत फ़ाइल (उर्फ main.c) में रखें। लेकिन हर एक फ़ाइल में लेखकों को सूचीबद्ध करके अपने आप को दोहराएं नहीं।

Answer 9

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

Answer 10

मैं Doxygen का उपयोग करता हूं बहुत ज्यादा सब कुछ के लिए शैली (या कभी-कभी कर्नेलोक) टिप्पणियों का । मैं ज्यादातर C और PHP में काम करता हूं, जहां Doxygen काफी लोकप्रिय है।

ज्यादातर मामलों में, यह कम से कम निम्नलिखित जानकारी शामिल करने में सहायक है:

• इसे कॉपी करने के लिए अनुमति (या नहीं) / कंपनी या व्यक्ति के कॉपीराइट
• लेखक का नाम / ई-मेल
• तारीख लिखी
• अंतिम बार संशोधित तिथि

यह किसी को भी मदद करनी चाहिए जो फ़ाइल पर काम कर रहा है, उन्हें पता है कि उनके पास क्या है, वे इसके साथ क्या कर सकते हैं और अगर उन्हें ज़रूरत हो तो वे किससे मदद मांग सकते हैं। यह भी बताता है कि वे 10 साल की उम्र के हैं।

Answer 11

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

उदाहरण के लिए, डेल्फी 7 में उन सहायक CNTools के साथ उपयोग करके मैंने टाइप किया

///a [enter]

और बाहर आता है

//<author></author>

फिर मैं टाइप करता हूं

///d [enter]

और बाहर आता है

 //<date></date>

मुझे लगता है कि कुछ 3 पार्टी उपयोगिता से मेल खाती है, लेकिन मेरे लिए के रूप में - मैं एक मानक है कि मैं भी बनाने के लिए और खुद को भ्रष्ट नहीं किया है मिल सकता है।