क्या पुरानी टिप्पणियाँ एक शहरी मिथक हैं?

38

मैं लगातार लोगों को यह दावा करते देखता हूं कि "टिप्पणियां पुरानी हो गई हैं।" बात यह है, मुझे लगता है कि मैंने अपने पूरे करियर में दो या तीन पुरानी टिप्पणियों को देखा है। अलग-अलग दस्तावेज़ों में आउटडेटेड जानकारी हर समय होती है, लेकिन मेरे अनुभव में कोड में पुरानी टिप्पणियाँ केवल दुर्लभ हैं।

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

comments myth

— कार्ल बेवफेल्ड
स्रोत

30

माना। एक टिप्पणी में बनाया गया आउटडेटेड कोड, अब यह एक ऐसी चीज है जिसे मैं बहुत कुछ देखता हूं - और कम देखना चाहूंगा।

— प्यावी

8

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

— पी। ब्रायन। मैके

2

मैंने बहुत सारी पुरानी टिप्पणियाँ देखी हैं, कुछ ईवीआईएल को केवल भ्रामक बता रहे थे। निश्चित रूप से कोई मिथक नहीं है, लेकिन ज्यादातर उन परियोजनाओं के लिए मान्य है जो कई लोगों द्वारा और / या लंबे समय तक बनाए रखा जाता है, जटिलता द्वारा प्रवर्धित होता है। हालाँकि मैंने कोड पर भरोसा करना सीखा, न कि टिप्पणियों पर (मैंने लगभग उन्हें कभी नहीं पढ़ा अगर वे एक से अधिक दो पंक्तियों से अधिक हों)।

— MaR

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

— एसके-तर्क

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

— कार्ल बेज़ेलफेल्ट

33

निरंतर

मैं वास्तव में विश्वास नहीं कर सकता कि मैं पुरानी और भ्रामक टिप्पणियों में केवल एक ही तैराकी हूँ। बंद मौके में यह समझने में मदद करता है:

यह शायद कोड की उम्र पर सबसे महत्वपूर्ण रूप से निर्भर करता है। अगला कारक कर्मचारियों पर कारोबार होगा।

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

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

मैं लगभग सभी सेवाओं में काम करता हूं, यहां तक कि हमारे उत्पाद एक विशेष ग्राहक के लिए अत्यधिक अनुकूलित हैं।

विशिष्ट उदाहरण:

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

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

— स्टीव जैक्सन
स्रोत

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

— स्टीवन ज्यूरिस

5

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

— स्टीव जैक्सन

1

@ साइट: आपकी स्थिति में मैं बस एक स्क्रिप्ट बनाऊंगा जो सभी टिप्पणियों को हटा देती है, और जहां आवश्यक हो, वहां से टिप्पणी करना शुरू करें। :)

— स्टीवन ज्यूरिस

1

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

— रिफ्लेक्टर की

4

मैंने कुछ भयानक उदाहरण देखे हैं

Blocks of copy-pasted code including comments. Comment may have made sense in its original location, but hardly makes sense here

। एक अलग वर्ग के बारे में बात करते हुए कक्षा-स्तर की टिप्पणियां, उदाहरण के लिए।

— पीटर टेलर

18

"टिप्पणियाँ पुरानी हो जाती हैं।"

मैंने देखा है कि ऐसा अक्सर होता है यह जानने के लिए कि यह एक समस्या हो सकती है।

बात यह है, मुझे लगता है कि मैंने अपने पूरे करियर में दो या तीन पुरानी टिप्पणियों को देखा है।

मेरा मानना है कि ऐसे माहौल में काम करना पूरी तरह से संभव होना चाहिए जहां हर कोई टिप्पणियों का पर्याप्त ध्यान रखता है और उन्हें बनाए रखता है। आपके द्वारा संपादित किए जा रहे कोड के पास टिप्पणियों को देखने और उचित होने पर उन्हें अपडेट करने के लिए यह केवल एक छोटा सा अतिरिक्त प्रयास है। मामले में टिप्पणियाँ इतनी दूर हैं कि आप तुरंत उन्हें नोटिस नहीं करते हैं, वे वैसे भी खराब टिप्पणियां थीं, और उन्हें पहले स्थान पर नहीं जोड़ा जाना चाहिए (या कम से कम वहां नहीं)।

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

Roehm et al द्वारा हाल ही में किया गया एक अध्ययन । 2012 निम्नलिखित देखता है:

21 प्रतिभागियों [28 में से] ने बताया कि उन्हें स्रोत कोड और इनलाइन टिप्पणियों से अपनी मुख्य जानकारी मिलती है जबकि केवल चार ने कहा कि प्रलेखन उनकी सूचना का मुख्य स्रोत है।

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

_{रोहम, टी।, टायर्क्स, आर।, कोस्चके, आर।, और मलेज, डब्ल्यू (2012, जून)। कैसे पेशेवर डेवलपर्स सॉफ्टवेयर समझाना ?. सॉफ्टवेयर इंजीनियरिंग पर 2012 के अंतर्राष्ट्रीय सम्मेलन की कार्यवाही में (पीपी। 255-265)। IEEE प्रेस।}

— स्टीवन ज्यूरिस
स्रोत

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

— पॉल नाथन

3

@Paul नाथन, टिप्पणियों को कभी भी यह नहीं बताना चाहिए कि कोड क्या करता है - कोड बेहतर वर्णन करता है। टिप्पणियाँ यह समझाने के लिए होती हैं कि कोड क्यों करता है।

— एसके-लॉजिक

2

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

— स्टीवन ज्यूरिस

हाँ, मैंने एक प्रलेखन शामिल नहीं किया (उदाहरण के लिए, Javadoc) - इसे केवल " टिप्पणी " कहा जाना संरचित है ।

— लॉजिक

17

निकृष्ट टिप्पणी एक नौकरी की गंध है। यह पुरानी या उपेक्षित इकाई परीक्षणों के होने जैसा है - यह दर्शाता है कि जो अच्छी प्रक्रियाएँ कभी दुकान पर सक्रिय थीं, वे काउल कोडिंग में बदल रही हैं। चीजों को ठीक से करने के लिए समय लेने की उचित "इंजीनियरिंग संस्कृति" टूट गई है। परियोजना / कंपनी के तकनीकी ऋण में जाने की संभावना है।

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

— बॉबी टेबल्स
स्रोत

"निकृष्ट टिप्पणी एक नौकरी की गंध है।" बहुत अच्छी तरह से डाल दिया! इसी तरह बिना किसी टिप्पणी के केवल स्व-दस्तावेजीकरण कोड ही समाधान नहीं है, बल्कि एक आलसी 'हैक' है।

— स्टीवन ज्यूरिस

10

टिप्पणियाँ परीक्षण की तरह हैं, वे बहुत अच्छे होते हैं जब वे अद्यतित होते हैं, लेकिन कोड को समझने के लिए और भी कठिन बना सकते हैं यदि नहीं हैं।

यदि आपने कभी कोई पुरानी टिप्पणी नहीं देखी है, तो आप बहुत भाग्यशाली रहे हैं।

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

— Kim.Net
स्रोत

क्या मैं पूछ सकता हूं कि आपने किन उद्योगों में काम किया है? मैं सोच रहा था कि यह दूसरों की तुलना में कुछ अधिक सामान्य है।

— कार्ल बेलेफेल्ट

मैंने यूरोप में 3 अलग-अलग देशों में काम किया है, ज्यादातर एक बड़ी कंपनी और एक छोटे के लिए एक सलाहकार के रूप में। सास विकास के घर में

— किम.नेट

यह भी देखें: "टिप्पणियाँ एक कोड गंध हैं"

— gnat

10

आउटडेटेड टिप्पणियाँ अक्सर JavaDoc में दिखाई देती हैं:

तर्कों को सूचीबद्ध करना जो अब मौजूद नहीं हैं
सभी तर्कों को न समझाते हुए (लापता को संभवतः बाद में जोड़ा गया था)
अपवादों आदि के लिए समान बातें।

इसके अतिरिक्त, कभी-कभी राज्य की चीजें जैसे "प्रदर्शन के लिए यहां करें" जैसी टिप्पणियां करती हैं, जब अधिकांश प्रदर्शन विचार कोड से भी तेज हो जाते हैं।

— डेकार्ड
स्रोत

3

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

— माइकल के

1

यह बता सकता है कि मैंने बहुत सारे क्यों नहीं देखे हैं। मैंने कभी भी कहीं काम नहीं किया है जो JavaDoc- शैली टिप्पणियों का उपयोग करता है।

— कार्ल नेवलेफेल्ट

4

@ माइकल, आईडीई चेतावनी हल्के मामलों में मददगार होती है। हमारी विरासत कोडबेस 20,000 चेकस्टाइल चेतावनियों का उत्पादन करती है, यह उस सीमा से अधिक है जहां आप ध्यान देना बंद कर देते हैं: - (((IDEs, जब बुरी तरह से उपयोग किया जाता है, तो Javadoc दुख में महत्वपूर्ण योगदान दे सकता है। हमारे कोडबेस में अधिकांश बकवास Javadoc स्पष्ट रूप से स्वतःपूर्ण थी।

— पेटर टॉर्क

4

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

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

featureList = GetFeatures();

// Sorting features and deleting empty ones from the list...
ProcessFeatures(featureList);

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

— Dyppl
स्रोत

3

अपने आप से यह पूछें। क्या आपने कभी कोड की एक पंक्ति को बदल दिया है और संबंधित टिप्पणियों को नहीं बदला है या नए जोड़े हैं?

मैंने बहुत सी विरासत कोड के साथ काम किया है और टिप्पणियां कभी-कभी प्रासंगिक भी नहीं होती हैं।

— बिल लीपर
स्रोत

2

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

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

— डेव वाइज
स्रोत

2

मुझे बहुत सारी वर्णनात्मक टिप्पणियां दिखाई नहीं दे रही हैं, लेकिन मुझे बहुत सारी TODO टिप्पणियां दिखाई देती हैं जो वर्षों से हैं। काश वे समय कैप्सूल की तरह होते और कुछ इस तरह कहते:

//TODO: In 15 years AND NO SOONER... actually implement this method.

— मॉर्गन हेरलॉकर
स्रोत

1

इस मामले में समस्या संभवतः TODOs का दुरुपयोग है। मेरा मानना है कि TODO का उपयोग केवल तब किया जाना चाहिए जब कोड वास्तव में कार्यात्मक हो लेकिन बाद में सुधार किए जा सकते हैं, इसलिए इस TODO: implementतरह की टिप्पणियां मौजूद नहीं होनी चाहिए और यह तथ्य कि कोई भी वास्तव में वापस नहीं आया है, इससे कोई फर्क नहीं पड़ता। अफसोस की बात है, बहुत सारे लोग इस नियम का पालन नहीं करते हैं और मैं पूरी तरह से सहमत हूं कि मैं कुछ टिप्पणी करना चाहता हूं जैसे कि आप कुछ बिंदुओं पर कुछ उत्पादन कोड में पोस्ट करते हैं। यह मेरा दिन बना देगा।

— pwny

1

C # में मैं उन उद्देश्यों के लिए NotImplementedException का उपयोग करता हूं ।

— स्टीवन ज्यूरिस

2

@pwny, मैं केवल उन चीजों पर TODOs का उपयोग करता हूं, जिन्हें मैं चेक करने से पहले लिखने की योजना बनाता हूं, यह सुनिश्चित करने के लिए कि मैं इसे कवर करता हूं। मेरी राय में इसके बजाय बग ट्रैकर में कुछ भी लंबे समय तक रहता है।

— कार्ल बेवेलफेल्ट

@ कार्ल बेलेफेल्ट जो बहुत अच्छी तरह से समझ में आता है।

— pwny

2

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

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

— jwenting
स्रोत

1

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

आपको किसी एप्लिकेशन के एक बड़े टुकड़े को बर्बाद करने और अपना बहुत सारा समय बर्बाद करने के लिए केवल एक बुरी टिप्पणी पर निर्भर रहना होगा।

— JeffO
स्रोत

0

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

— गौरव सहगल
स्रोत