क्या TODO टिप्पणियों से समझ में आता है? [बन्द है]

86

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

//TODO translations

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

क्या यह टिप्पणी लिखने के लिए समझ में आता है या क्या उन्हें एक व्हाइटबोर्ड / पेपर / कुछ और लिखा जाना चाहिए जहां वे डेवलपर्स के ध्यान में रहते हैं?

documentation comments

— इवान क्रॉजैक कारिकोव
स्रोत

2

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

— smp7d

3

मेरे लिए TODO अधिक है जैसे "अनुकूलन करने के लिए करना चाहिए, लेकिन जहाज के लिए अनावश्यक"

— जेक बर्गर

8

जब भी मैं कोई ऐसा कार्य करने की सोचता हूं या उस किनारे वाले मामले की, जिसे मैं जिस मौजूदा फीचर पर काम कर रहा हूं, उसके लिए जांच करने की जरूरत है, मैं जो लिख रहा हूं (यहां तक कि मध्य-कथन) को रोक देता हूं और इसके लिए एक TODO भी जोड़ देता हूं (भले ही यह सिर्फ ऊपर की रेखा है) । यह उन "ओह, हाँ, मुझे उस" कीड़े के बारे में भी सोचने से रोकने में मदद करता है । फीचर करने से पहले, मैं TODOs की जांच करता हूं। वे कभी कमिटेड नहीं होते हैं, लेकिन जब से मैंने ऐसा करना शुरू किया है, मेरी संख्या बहुत कम हो गई है ।

— ब्लूराजा - डैनी पफ्लुगुफ्ट

8

#warning TODO: …अगर मैं TODO को भूलना नहीं चाहता तो मैं हमेशा उपयोग करता हूं।

— राइटफोल्ड

2

@WTP: विजुअल स्टूडियो, आर #, नेटबीन्स, एक्लिप्स इत्यादि सभी में एक समाधान / कार्यक्षेत्र के भीतर सभी TODO को देखने के लिए उपकरण शामिल हैं। अब उस पुराने हैक की कोई आवश्यकता नहीं है।

— ब्लूराजा - डैनी पफ्लुगुफ्ट

107

मुझे // todoउन चीजों के लिए टिप्पणियों का उपयोग करना पड़ता है जो कि होनी हैं, लेकिन मैं तुरंत नहीं कर सकता।

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

लेकिन, जैसा कि आप कहते हैं, हर कोई उनके बारे में मेहनती नहीं है और कई टिप्पणियों की तरह, वे समय के साथ सड़ जाते हैं।

मैं कहूंगा कि यह एक व्यक्तिगत प्राथमिकता है - इसलिए जब तक आप दस्तावेज़ बनाते हैं कि उस पर क्या करना है और उसका पीछा करना है, इससे कोई फर्क नहीं पड़ता कि यह अंदर है // todo, नोट नोट करें या व्हाइटबोर्ड (जहां वे भी समाप्त हो सकते हैं कार्रवाई की जा रही है)।

— Oded
स्रोत

18

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

— हॉब्स

4

Resharper के पास TODOs की अच्छी लिस्टिंग है, यह डिफ़ॉल्ट VS एक (अधिक फ़ाइलों में दिखता है) की तुलना में बेहतर काम करता है।

— कैफीक

हां, आपके आईडीई में एक सूची दी गई, वे सहायक हैं। मैं कहूंगा कि वे बहुत सीमित उपयोग के हैं अन्यथा, क्योंकि कोडबेस भारी हो सकता है।

— इंजीनियर

4

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

— user1936

2

चूंकि ReSharper और तारीखें उल्लेख किया गया था मैं का एक सरल Resharper लाइव टेम्पलेट का उपयोग "// TODO $ उपयोगकर्ता $ ($ तिथि $) -"

— अंधेरे पिता

56

आधुनिक आईडीई TODOटिप्पणियों को पहचानते हैं और वे अपने स्वयं के पैनल / विंडो / टैब में ऐसे दिखाई देते हैं, इसलिए वे सैद्धांतिक रूप से खो नहीं जाते हैं (मैं ग्रहण और दृश्य स्टूडियो सोच रहा हूं, दोनों मुझे यह याद रखने के लिए पर्याप्त हैं कि वे इसे पहचानते हैं)।

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

अब, मैंने "सैद्धांतिक रूप से" लिखा, क्योंकि हालांकि हार नहीं हुई, टीओडीओ अधिक बार उस चीज से संबंधित है जिसे "फिलहाल" ठीक से काम करने के लिए आवेदन की आवश्यकता नहीं है। और "फिलहाल" परियोजना के प्रकार / आकार के आधार पर 5 मिनट से 5 साल तक बढ़ सकता है :-)

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

संपादित करें: जैसा कि टिप्पणियों पर विकिपीडिया के लेख में लिखा गया है , जिसमें TODO की तिथि और स्वामी को एक अच्छा अभ्यास माना जाता है।

— जलयोन का पता चलता है
स्रोत

32

मुझे लगता है कि टीओडीओ की तारीख और मालिक सिर्फ शोर है। यही संस्करण नियंत्रण (और दोष सुविधा) के लिए है (यदि आपको वास्तव में जानकारी की आवश्यकता है)।

— साल्स्के

3

मुझे नहीं लगता कि एक विकिपीडिया कहता है कि "यह सलाह दी जाती है" किसी भी धर्मार्थ है; गंध की चेतावनी। यह दावा करने वाले लेख का बेहतर लिंक।

— डेसट्रेल

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

— जलयान

@ मुझे लगता है कि मैं कम से कम शोर रखने के बारे में सहमत होना चाहूंगा लेकिन मुझे लगता है कि आईडीई आपको स्वचालित रूप से रिपॉजिटरी से वह जानकारी नहीं देता है (जब तक कि मैं गलत नहीं हूं, आपको मैन्युअल रूप से संस्करणों की तुलना करनी होगी) यदि आप स्पष्ट रूप से इसे नहीं लिखते हैं। ।

— जलयन्

1

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

— एक CVn

13

यह कुछ समझ में आ सकता है, कम से कम मैं कभी-कभी उनका उपयोग करता हूं। मुख्य बिंदु लगातार टैग का उपयोग करना है जैसे कि TODOया FIXMEताकि उन्हें सरल पाठ खोज के साथ आसानी से पाया जा सके।

उदाहरण के लिए, "त्वरित 'गंदे" समाधान लेबल के लिए सुविधाजनक हैं, जैसे कुछ:

ConnManager.getConnection("mydatabase"); // FIXME: DB name should be configurable

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

— जूनस पुलका
स्रोत

3

"FIXME" और "TODO" का मेरे लिए अलग अर्थ है। एक अनुवाद, एक हार्ड-कोडित मूल्य, या एक अपवाद को पकड़ना ex.printStacktrace()मेरे लिए TODO हैं। दूसरी ओर, FIXME कभी-कभी होने वाले एक्सेप्शन, एक मेमोरी लीक, या किसी अन्य प्रकार के बग से निपटता है जो आपने स्थित है लेकिन पूरी तरह से विश्लेषण / तय नहीं किया है।

— आरडीएस

10

मेरे उद्योग में, डेवलपर्स को टूडो टिप्पणियों के बजाय JIRA (या आदि) प्रविष्टियां करने के लिए प्रोत्साहित किया जाता है क्योंकि हर किसी को // todoप्रविष्टियों को देखने का मौका नहीं मिलता है । लेकिन कभी-कभी बड़ी परियोजनाओं में एक कस्टम विशेषता की तर्ज पर परिभाषित किया जाता है:

[AttributeUsageAttribute(AttributeTargets.All, AllowMultiple = true)]
public class DeveloperNote : Attribute
{
    public DateTime EntryDate { get; set; }
    public string Description { get; set; }
    public DeveloperNote(int year, int month, int day, string desc)
    {
        EntryDate = new DateTime(year, month, day);
        Description = desc;
    }
}

और फिर एक विधि को इस तरह से सजाया जा सकता है ...

[DeveloperNote(2011, 12, 13, "Make the db connection configurable")]

और उच्च अप के साथ आ सकते हैं और इन स्वचालित रूप से कटाई कर सकते हैं। यह सरल // todoअनुस्मारक के लिए ओवरकिल हो सकता है , लेकिन यह प्रभावी है। साथ ही इसके लिए एक .NET प्लेटफॉर्म की आवश्यकता होती है।

— गैरी
स्रोत

5

एक TODO टिप्पणी को एक लाइन कोड के लिए lcoalized किया जाता है। मेरी राय में एक टिकट अधिक वैश्विक और उच्च स्तर का है। और मैं इस एनोटेशन एक overkill है thinnk करते हैं। TODO के पास अधिक संपादकों पर काम करने का अधिक मौका है।

— आरडीएस

6

आपका उद्योग? वह कौन सा है? मैं एक पूरे उद्योग को नहीं जानता जो JIRA उपयोग को प्रोत्साहित करता है ?!

— Febesnel

7

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

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

— पीट मनसिनी
स्रोत

1

यदि यह एक दशक से अधिक समय से हो रहा है, तो इसकी वास्तव में जरूरत नहीं थी और इस तरह एक TODOटिप्पणी को जोड़ने से कोई मतलब नहीं था।

— बजे एक CVn

2

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

— पीट मनकीनी

6

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

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

मेरी प्राथमिकता हमेशा यही रहेगी कि मैं इनका उपयोग न करूं और इसके बजाय उचित स्टोरी कार्ड या बैकलॉग या इसी तरह का उपयोग करूं। एक कार्य के लिए एक तंत्र का उपयोग करें।

— मैनफ्रेड
स्रोत

6

मैं उन्हें अतीत में लिखता था, लेकिन मैंने पाया है कि आप आमतौर पर उनका अनुसरण नहीं करते हैं।

इसलिए अब मैं केवल उन चीजों को चिह्नित करने के लिए उपयोग करता हूं जिन्हें मैं ठीक करने के बाद काम करना चाहता हूं। उदाहरण के लिए, मैं एक नया फ़ंक्शन लागू करता हूं और ध्यान देता हूं कि मेरे द्वारा उपयोग किए जाने वाले फ़ंक्शन में एक छोटा बग है; मैं अपने मौजूदा कार्य में पटरी से उतरने से बचने के लिए इसे ठीक करने के लिए एक FIXME बनाता हूं।

मेरी मदद करने के लिए, हमारे सीआई बिल्ड को विफल करने के लिए सेट किया गया है अगर कोड में FIXMEs हैं :-)।

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

वैकल्पिक रूप से, आप फिर बग ID :-) के साथ TODO में डाल सकते हैं।

— sleske
स्रोत

3

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

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

ConnManager.getConnection("mydatabase"); // FIXME: DB name should be configurable

आप इसे कुछ इस तरह बदल सकते हैं

ConnManager.getConnection(GetDatabaseName());

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

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

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

— एक CVn
स्रोत

3

यदि आप एक TODO या FIXME को इस विचार के साथ लिखते हैं कि कोई और इसे ठीक करेगा जब वे कुछ अनिश्चित भविष्य में उस कोड पर आएंगे तो मैं कहूंगा कि परेशान मत करो। वे कोड को लिटायेंगे और आपके IDE के रिपोर्टिंग भाग को अव्यवस्थित करेंगे जो इस जानकारी को एकत्र करता है।

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

वास्तव में जो कुछ भी रहता है उसे आपके बग बेस में रखा जाना चाहिए जहां वह है।

हमारे जीवन में पर्याप्त शोर है, आइए सामान की एक नई धूमधाम न बनाएं जो ध्यान के लिए चिल्लाता है जबकि इसे कहीं और आवश्यक है।

मेरा 2 प्रतिशत

— न्यूटोपियन को दर्शाता है
स्रोत

2

आमतौर पर मैं TODO टिप्पणियां नहीं करता हूं, लेकिन उन सभी को अलग फ़ाइल में रखते हैं। फिर भी ऑनलाइन सॉफ्टवेयर को आसानी से प्रबंधित करने के लिए उन्हें लिखने / लिखने के लिए नहीं मिल सकता है इसलिए TODO फाइलें अभी भी मेरे लिए सबसे उपयोगी हैं क्योंकि जब मैं कम समय के बाद परियोजना को खोलता हूं तो मैं भूल जाता हूं कि अब क्या करना है और फिर मैं TODO फाइल को देखता हूं और काम करता हूं । मुझे "filename.cpp 354 मिला है: इस bla bla bla को पुनः प्राप्त करें" और यह बहुत अधिक उपयोगी है, तो खोज // TODO फ़ाइल में टिप्पणी करें। मैंने // TODO ईयरलर तब किया जब मैं आलसी था लेकिन मैं स्रोत फ़ाइल से उन पुराने // TODO-s को हटा देता हूं और जब परियोजना अच्छी तरह से काम करती है तो उन्हें ठीक नहीं करती। मैं दृढ़ता से सभी // TODOs को अलग-अलग जगह से स्थानांतरित करने की सलाह देता हूं और उन्हें अन्य todos के साथ जोड़कर रख सकता हूं ताकि आप कार्यों को आसानी से प्राथमिकता दे सकें। जब आप अपने सभी TODO को विभिन्न फ़ाइलों और विभिन्न परियोजनाओं में प्राप्त करते हैं तो प्राथमिकता वास्तव में TODO के लिए बहुत कठिन है।

— CND
स्रोत

7

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

— 13

हां आप सही हैं) कभी-कभी मेरे लिए लाइन ढूंढना मुश्किल होता है लेकिन मैं इससे निपटता हूं। और हाँ। मैं फ़ाइल या आईडीई में आसान खोजने के लिए दोनों का उपयोग कर सकता हूं, लेकिन यह जानने के लिए कि अलग-अलग जगह क्या करना है।

— CND

2

मुझे लगता है कि वहाँ महान है, लेकिन अकेले नहीं। उदाहरण के लिए:

//TODO: ADD MY CLICK EVENT LOGIC
throw new Exception();
//Even a simple messageBox could suffice

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

— एडवर्ड
स्रोत

2

उस मामले में आप बस एक फेंक सकते हैं new NotImplementedException()जिसका तात्पर्य एक ToDo है।

— कोडइन्चौस

CI में उपयोग करना पसंद है assert(0 && "TODO[cmaster]: Add click event logic");। मेरे लिए संदेश प्राप्त करने में सरल और बहुत प्रभावी, क्या मुझे TODO को भूल जाना चाहिए ...

— 21

1

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

संभवतः इस तरह से सामान के लिए अधिक उपयुक्त स्थान कोड के बजाय मुद्दा ट्रैकर है।

— व्याट बार्नेट
स्रोत

0

मैं दृढ़ता से सलाह देता हूं कि प्रत्येक TODO या FIXME को एक औपचारिक लॉग में प्रवेश किया जाए। यदि वे नहीं हैं, तो वे आसानी से खोजे जा सकते हैं, और प्रत्येक TODOs और FIXMEs के लिए जाँच करने के लिए प्रत्येक पुनरावृत्ति में यह एक चरण होना चाहिए। फिर इन्हें सूचीबद्ध किया जा सकता है, और या तो तत्काल उपाय के लिए सेट किया जा सकता है, या टीम उचित समय पर उन्हें ठीक करने की योजना बना सकती है।

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

नीचे पंक्ति: वे सभी मुद्दों को लॉग न करने से बेहतर हैं, लेकिन आपको वास्तव में उन्हें बनाए रखना होगा।

— मार्सिन
स्रोत

-1

अगर आप नए TODOs कोड बनाने की कोशिश करते हैं, तो IntelliJ वास्तव में आपको सचेत करेगा। इसलिए, आप हमेशा TODO की व्याख्या कर सकते हैं कि "यह वास्तव में मेरे द्वारा किए जाने वाले समय तक होना चाहिए"।

— ripper234
स्रोत

-1

जब आप "TODO" को अपनी टिप्पणी के लिए शब्दार्थ लेबल मानते हैं तो मुझे लगता है कि वे समझ में नहीं आते हैं।

मेरी कंपनी के कोडिंग मानकों में, हम निर्दिष्ट करते हैं कि ज़िम्मेदार डेवलपर के आरंभ को TODO ( यानी , मुझे "SAA TODO:") लिखना होगा। मुझे लगता है कि यह उपयोगी है, कम से कम एक सम्मेलन के रूप में, क्योंकि अन्यथा कुछ भविष्य के डेवलपर से निपटने के लिए TODO नोट के साथ घटिया कोड छोड़ने का प्रलोभन है।

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

— स्टीवर्ट
स्रोत

-2

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

डेल्फी में:

{$message 'todo: free this thing when you know its not going to blow up'}

— पीटर टर्नर
स्रोत

-4

मेरे अनुभव में, TODOयह इंगित करने के लिए उपयोग किया जाना चाहिए कि कोड का एक टुकड़ा प्रयोग करने योग्य नहीं है और पाठक को बताता है कि इसे प्रयोग करने योग्य बनाने की आवश्यकता है (या तो स्थानीय रूप से या कहीं और)।

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

— मार्टिन जाम्बोन को दर्शाता है
स्रोत

क्या यह केवल आपकी राय है या आप इसे किसी तरह वापस कर सकते हैं?

— gnat

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

— मार्टिन जाम्बोन