कई सालों के लिए मेरी कोड टिप्पणियां इस तरह से भरा हुआ था:@todo प्रोग्रामिंग सामग्री का प्रबंधन कैसे करें?
//TODO : Add ...
...
/*
*TODO : Fix ...
*
*/
अब मैं अपने खुद के @todo जावाडोक एनोटेशन बनाने के लिए लगता है ... लेकिन कर रही है कि मुझे पता है कि अगर आप लोग बेहतर तरीका हो करना चाहते से पहले अपने todo प्रोग्रामिंग सामग्री का प्रबंधन करने के लिए?
आपका आईडीई (ग्रहण, नेटबीन, ..) में एक कार्य प्लगइन है, जो सभी TODO एस का पता लगाता है और उन्हें एक सूची में दिखाता है। ग्रहण में यह Window > Show View > Other > Tasks
अपनी खुद की एनोटेशन लिखने की आवश्यकता नहीं है।
पर एक नज़र डालें, यह एक्शन आइटम –
छोटे कार्यों जैसे कि मेरे सामान्य // todo मैं बड़े कार्यों के लिए एक्लिप्स माइलिन में स्थानीय कार्यों का उपयोग करता हूं (भले ही मुझे लगता है कि उन्हें विशेषताओं या बग कहा जा सकता है) मैं ट्रैक का उपयोग करता हूं; यदि आपको TODO से भरा कोड मिलता है तो यह टिकट प्रबंधन प्रणाली प्राप्त करने का समय है।
विम के लिए यह Tasklist स्क्रिप्ट भी है, जो ग्रहण की कार्य सूची से प्रेरित है, जो आपकी टेक्स्ट फ़ाइलों में TODO, FIXME इत्यादि के लिए स्क्रैप करता है और उन्हें अतिरिक्त बफर में एक सूची के रूप में प्रदर्शित करता है (screenshot देखें)।
है, मुझे यह पता नहीं था। धन्यवाद! –
मैं मूल रूप से यह करें आइटम के विभिन्न प्रकार के लिए तीन प्रणालियों का उपयोग करें: अल्पकालिक आइटम (आज या इस हफ्ते की तरह)
इश्यू ट्रैकर (और पेपर!) के लिए +1 –
हो सकता है कि आप पाते हैं का उपयोग कर सकते हैं और ग्रेप तरह समस्या ट्रैकर उन कुंजी के लिए खोज करने के लिए आपकी परियोजनाओं में शब्द
टोडो झंडे के साथ समस्या चेतावनियों के समान है (उदा। जावा कंपाइलर, चेकस्टाइल)। अगर वे अक्सर प्रकट होते हैं, तो आप उन्हें अनदेखा करेंगे। आपके मामले में मैं उन्हें बिल्ड-सिस्टम (जैसे मैवेन या चींटी) द्वारा एक रिपोर्ट के माध्यम से ट्रैक करता हूं। प्रत्येक पुनरावृत्ति के अंत में आपको एक नियम बनाना चाहिए, कि टॉडो झंडे की संख्या कम हो जाती है।
कम कार्य करने-झंडे का अर्थ है:
आम तौर पर कार्य करने का उपयोग नहीं करते सभी कार्यों के लिए झंडे। मेरे लिए वे केवल थोड़ी अनुस्मारक या रिफैक्टरिंग-टोडोस हैं। बड़े कार्यों को हमेशा टिकट-प्रणाली (जैसे ट्रैक या जिरा) द्वारा ट्रैक किया जाना चाहिए।
हमने हडसन के लिए एक प्लग-इन का उपयोग किया जो समय के साथ TODO को दिखाता है - यह सार्वजनिक और दृश्यमान है, जिसका अर्थ है कि समय के साथ इसे कम करने के लिए और अधिक ड्राइव है। – SteveD
शायद डॉक्सिजन आपकी मदद कर सकता है?
डॉक्सीजन उन /// @ TODO: एस को पहचानता है और उनके साथ एक सूची बनाता है।
और चूंकि डॉक्सिजन जावाडोक शैली टिप्पणियों का उपयोग कर सकता है, मुझे लगता है कि इसे आजमाने में आसान है।
यदि आपके TODO कथन आपको बहुत अधिक परेशान कर रहे हैं और उन्हें देखकर आपको बहुत अधिक परेशानी हो रही है तो मैं निर्माण प्रक्रिया में एक छोटी सी लिपि लिखूंगा जो संकलन का पता लगाता है और विफल रहता है।यह वैसे ही असफल हो जाता है कि यह चेतावनी बयान पर विफल रहता है।
मैं फ़िक्स का उपयोग करता हूं! TODO के बजाय। विस्मयादिबोधक बिंदुओं की संख्या प्राथमिकता को इंगित करती है। IntelliJ आपको इनके लिए कस्टम फ़िल्टर सेट अप करने देता है, इसलिए मैं स्तर -3 "फिक्स !!!" देख सकता हूं टिप्पणियां और उनसे निपटें।
मैं @todo जावाडोक एनोटेशन का उपयोग नहीं करता क्योंकि आईएमओ इसे दस्तावेज़ीकरण में नहीं जाना चाहिए।
दस्तावेज़ीकरण सार्वजनिक होना चाहिए, जो TODO के लिए आदर्श नहीं है।
TODO को उन कोडों के पास भी जाना चाहिए, जो टिप्पणियों का उपयोग करने का एक लाभ है।
यदि आप मेवेन का उपयोग कर रहे हैं, तो आप taglist-maven-plugin का उपयोग टैग के लिए स्रोत फ़ाइलों (किसी भी टैग को आप चाहते हैं, यह कॉन्फ़िगर करने योग्य) स्कैन करने के लिए कर सकते हैं और a report को उनकी घटनाओं पर उत्पन्न करता है।
Taglist Maven प्लगइन विभिन्न टैग पर एक रिपोर्ट कोड में पाया,
@todoया//TODOटैग
लेकिन ट्रैकिंग टैग, आसान हिस्सा है, इन्हें ठीक तरह उत्पन्न करता है थोड़ा मुश्किल और अधिक समय लगता है :)
+1: मैं सिर्फ एक नमूना रिपोर्ट बोता हूं: वास्तव में दिलचस्प !! –
TODO कथन हमेशा कोड में छोड़े जाने का जोखिम लेते हैं, जो खराब है क्योंकि // TODO elaborate answer
कोड में हमेशा के लिए वास्तविक समस्या/समस्या को छोड़कर –
@ ओलिवर वाटकिन्स मैं सहमत हूं। TODO में कम से कम दो फायदे हैं: यह किसी लंबित मुद्दे के रूप में कुछ पहचानता है, और इसे खोजना आसान है। इसके बावजूद, मैंने दर्जनों TODO टिप्पणियां देखी हैं जिन्हें उनके लेखकों द्वारा "हल" नहीं किया गया था। मेरे लिए, यह सिर्फ अधूरा काम है। –
मैं आमतौर पर TODO के बगल में एक टिकट नंबर लिखता हूं, इसलिए कोई भी जो कोड पर ठोकर खाता है, कुछ अन्य कार्य करते समय, यह देखेगा कि इस स्थान पर कौन सा तकनीकी ऋण मौजूद है। यह विश्लेषण करना आसान बनाता है कि यह कार्य पूरा करने को कैसे प्रभावित कर सकता है (उदाहरण के लिए कि आपको यह तकनीकी ऋण समाप्त करना होगा, या आपका कार्य अनुमानित से अधिक कठिन हो सकता है)।यदि कोड में कोई TODO नहीं है, तो आप कुछ व्यावसायिक आवश्यकता के दौरान पूरा कर चुके तकनीकी ऋण से अनजान हो सकते हैं। – user3707125
TODO एक छोटी टीम में ठीक है, लेकिन यदि आप ओपन-सोर्स प्रोजेक्ट या किसी भी तरह से डेवलपर एक्सेस को विस्तृत करते हैं, तो अन्य प्रकार जैसे TO_DO, fixme, XXX, नोट, हैक, बग, "your_defect_tool_here" और इसलिए स्कैनिंग की आवश्यकता है वैसे भी। थोड़ा दिग्गज, लेकिन मेरे TODO प्रोटोकॉल लगेगा जैसे:
कार्यसूची: yy-mm-dd: लेखक: आपकी_टिप्पणी
अन्त में टिप्पणी आप सामरिक, नहीं एक डिजाइन बयान या राय छोड़ करते हैं।
यह भाषा अज्ञेयवादी हो सकता है ... –
एनोटेशन भाषा अज्ञेयवादी नहीं हैं ... – TofuBeer
@Martinho & TofuBeer: यह स्रोत कोड टिप्पणी है ... ज्यादातर मामलों में यह भाषा के लिए कसकर है ... लेकिन "बहुभाषी" परियोजनाओं में आईडीई की तरह एक अज्ञेय समाधान बहुत अच्छा हो सकता है ... –