TODO वास्तव में 'करने के लिए' नहीं होते

 (sophiebits.com)
15 पॉइंट द्वारा GN⁺ 2025-07-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • कुछ टीमें सभी TODO comments को bug tracker में दर्ज करने या 1 साल से पुराने TODO को अपने-आप हटाने जैसी नीति अपनाती हैं, लेकिन ऐसी प्रथाएँ सिफारिश योग्य नहीं हैं
  • TODO comments ज़रूरी नहीं कि केवल वही चीज़ें हों जिनकी पूर्णता ही उनका मूल्य तय करती है; वे कोड लिखे जाने के समय के संदर्भ और विचारों का दिमागी स्नैपशॉट भी होते हैं
  • महत्वपूर्ण TODO को issue के रूप में मैनेज किया जाना चाहिए, लेकिन अधिकांश TODO कम प्राथमिकता वाले या edge case दर्ज करने वाले नोट्स होते हैं
  • सही जगह रखा गया TODO भविष्य में कोड पढ़ने वाले व्यक्ति को "क्या इस हिस्से को refactor करना ठीक होगा?" जैसे सवाल पर उस समय के लेखक की मंशा समझने का संकेत देता है
  • TODO का मूल्य पूरा होने में नहीं, बल्कि संदर्भ, मंशा और संभावनाएँ दर्ज करने में है, जिससे भविष्य के maintenance और collaboration में मदद मिलती है

TODO comments, क्या इन्हें ज़रूर निपटाना चाहिए?

  • कुछ संगठन कोड के भीतर मौजूद सभी TODO को bug tracker में दर्ज करते हैं, या एक तय अवधि (1 साल से अधिक) बीतने पर उन्हें अपने-आप हटाने का नियम लागू करते हैं
  • लेकिन यह तरीका वास्तव में अप्रभावी है और TODO की असली प्रकृति को नज़रअंदाज़ करता है — उनका मूल्य केवल निपटाए जाने में नहीं है

TODO का असली मूल्य

  • उदाहरण के लिए,

    // TODO: 다음 주 출시 전에 이 파일의 뒷부분을 완성해야 함

    जैसी टिप्पणी को वास्तव में ट्रैक करने की ज़रूरत हो सकती है

  • लेकिन अच्छे TODO आम तौर पर

    // TODO: 사용자가 이 버튼을 트리플 클릭할 경우, 핸들러에서 \[xyz] 오류 발생

    की तरह edge case को दर्ज करने, ऐसे structural improvement ideas जिन्हें अभी लागू नहीं किया जा सका, या छूट गई स्थितियों को संदर्भ सहित लिखकर रखने के लिए होते हैं

TODO 'योजना' नहीं, 'खिड़की' हैं

  • अधिकांश TODO वास्तव में ऐसी कम-प्राथमिकता वाली चीज़ें होते हैं जिन्हें तुरंत निपटाने की ज़रूरत नहीं होती
  • वे लिखे जाने के समय लेखक के विचार, निर्णय और context को भविष्य के code reader तक पहुँचाने का काम करते हैं
  • बाद में कोड पढ़ने वाला कोई व्यक्ति जब सोचे, "क्या यहाँ की संरचना बदली जा सकती है?", तब TODO उस समय के लेखक की मंशा समझने में मदद करता है

अच्छी तरह लिखे गए TODO का प्रभाव

  • कोड में मौजूद TODO कभी-कभी संभावित समस्याओं, structural improvement की गुंजाइश, और अनहैंडल्ड edge cases जैसे महत्वपूर्ण संकेत देते हैं
  • भले ही वे हमेशा किसी समाधान-योजना का हिस्सा न हों, collaboration और maintenance में सूक्ष्म संदर्भ पहुँचाने में उनकी बड़ी भूमिका होती है
  • अंततः TODO comments कोड की समझ और भविष्य की maintainability बढ़ाने वाले मूल्यवान रिकॉर्ड की तरह काम करते हैं

निष्कर्ष

  • TODO की कीमत केवल उन्हें पूरा करने में नहीं है; वे लेखक के विचार, मंशा और context को दर्ज कर भविष्य के code reader के साथ संवाद का माध्यम बनते हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-07-23
Hacker News राय
  • मेरा मानना है कि "TODO हमेशा किसी ठोस issue से जुड़ा होना चाहिए"
    मुझे लगता है कि merge से पहले TODO को संभालने के तीन तरीके हैं
    1. issue छोड़ना—अगर वह सच में किया जाने वाला काम है, तो लगभग 20 सेकंड लगाकर उसे दर्ज और track कर लेना अच्छा है
    2. तुरंत निपटा देना—अगर वह इतना छोटा काम है कि issue बनाने लायक नहीं, तो commit से पहले ही उसे ठीक कर देना चाहिए
    3. comment में बदल देना—अगर वह न तो ठीक करने लायक है, न track करने लायक, लेकिन याद रखना चाहते हैं, तो उसे सामान्य code comment के रूप में छोड़ना बेहतर है
    सेहत के लिए broccoli खाने की तरह, TODO को track करने की आदत भी अच्छी है
    • किसी external system में track करने का मतलब सिर्फ issue दर्ज करना नहीं, बल्कि categorization, backlog management, reclassification, और पूरा होने पर बंद करना जैसी अतिरिक्त मेहनत भी लगातार करनी पड़ती है
      external system में दर्ज issue उस code को छूने वाले developers को आसानी से दिखें, यह ज़रूरी नहीं
      अगर साधारण fixes तक को ज़बरदस्ती track करने की लागत ज़्यादा लगती है, तो उन्हें TODO के रूप में छोड़ देना अधिक प्रभावी है
      code के अंदर TODO उसी code पर काम करते समय तुरंत दिखाई देते हैं, और refactoring के दौरान आसानी से हटाए भी जा सकते हैं
    • लेख का लेखक मूल रूप से बिंदु 3, यानी बस comment के रूप में छोड़ देने, का समर्थन करता दिखता है
      लेकिन TODO comment और सामान्य comment के बीच फर्क को उसने साफ़ तौर पर नहीं बताया, यह थोड़ा खटकता है
      TODO शब्द में खुद एक visual ताकत होती है, जिससे तुरंत समझ आ जाता है कि यह किस तरह का comment है
      यह कहना थोड़ा संदिग्ध लगता है कि TODO comment को ज़रूरी नहीं कि "TO DO" यानी करने वाला काम ही माना जाए
      लेख की बातों से मैं कुल मिलाकर सहमत हूँ, लेकिन मुझे लगता है कि इसे सामान्य comment के रूप में छोड़ना ज़्यादा बेहतर सुधार होगा
    • कहा गया कि "20 सेकंड लगाकर बस दर्ज और manage कर लो", लेकिन वही तो असल में TODO है
      ticket system में डालो तो 20 सेकंड से ज़्यादा ही लगता है, और मदद करने के बजाय उल्टा ध्यान भटकाता है
    • track करना 20 सेकंड में हो जाए तो अच्छा है, लेकिन (बड़ी कंपनी में होने के कारण) एक JIRA ticket बनाने के लिए 10 से ज़्यादा mandatory fields भरनी पड़ती हैं
    • मैं सिर्फ एक नियम इस्तेमाल करता हूँ: हर TODO में ticket number ज़रूर होना चाहिए
      // TODO: improve the routing https://jira.com/whatever/TIX-1234
      वजह यह है कि अगर comment अनाथ हो जाए, तो किसी को पता नहीं चलता कि वह क्यों छोड़ा गया था
      अगर सिर्फ comment छोड़ दिया जाए, तो बाद में कोई उसका उद्देश्य और संदर्भ भूल जाता है
      इसलिए मेरे हिसाब से या तो ticket बनाओ, या तुरंत उसे निपटाओ
  • मैं grep करते समय इन्हें इस तरह अलग करता हूँ
    FIXME: जो साफ़ तौर पर गलत या टूटा हुआ हो, सबसे उच्च प्राथमिकता
    XXX: जो बदसूरत हो या गलत assumptions पर बना हो, उच्च प्राथमिकता
    TODO: जहाँ कभी न कभी पूरी तरह नया approach/category/branch लागू करना होगा
    NOTE: साधारण comment से अधिक महत्वपूर्ण जानकारी देने के लिए
    मैं ज़्यादातर legacy/maintenance न होने वाले code engine पर काम करता हूँ, और वहाँ "code ही सच है", इसलिए JIRA नहीं बनाता, बस पढ़ते-पढ़ते तुरंत सुधार देता हूँ
    • मैं इसे इस तरह इस्तेमाल करता हूँ
      TODO: release से पहले ज़रूर किया जाना चाहिए, अनिवार्य चीज़। अगर ऐसा नहीं है, तो इसे किसी और category में जाना चाहिए। यह release blocker है
      FUTURE: कभी TODO बन सकता है, आम तौर पर structural design जैसी optional चीज़
      MAYDO: हो तो अच्छा, न हो तो भी चलेगा
      PERF: जब performance की ज़रूरत हो, तब किया जा सकता है
      और मैं domain से जुड़े semantic tags भी इस्तेमाल करता हूँ
      मेरे हिसाब से TODO code smell नहीं है, बल्कि codebase के महत्वपूर्ण हिस्सों में स्वाभाविक रूप से जमा होने वाली चीज़ है
    • मैं XXX को "अगले PR से पहले ज़रूर ठीक करना है" वाले निजी memo की तरह इस्तेमाल करता हूँ
      अगर इसे गंभीरता से लागू करना हो, तो CI को इस तरह सेट करता हूँ कि वह उस string वाले code को reject कर दे
      इस अर्थ में XXX मेरे लिए सबसे उच्च प्राथमिकता है
    • यह style मुझे पसंद है। एक project में हमने CI से यह तय किया था कि FIXME वाला code हमेशा reject होगा, और TODO तभी स्वीकार होगा जब उसके साथ issue ticket हो
      ऊपर से नीचे प्राथमिकता इस तरह है
      FIXME: ध्यान बनाए रखने के लिए। इसे हल किए बिना code merge या complete नहीं माना जाएगा
      XXX: जल्द ठीक करना है। अभी काम करता है, लेकिन जल्दी ठीक होना चाहिए
      TODO: बाद में दोबारा देखना है। code पूरी तरह उपयोग योग्य है। XXX से कम प्राथमिकता
      NOTE: असामान्य बातों या ज़रूरी जानकारियों को समझाकर बाद में आने वाले व्यक्ति की मदद करना
    • मैं भी कुछ ऐसा ही करता हूँ। जो code path अभी अधूरा है लेकिन bypass किया जा सकता है, उसमें FIXME की जगह assert डालता हूँ
      TODO का उपयोग refactoring/performance/clarity improvements जैसे संभावित काम छोड़ने के लिए करता हूँ
      NOTE का उपयोग पुराने context या ऐसे thought process को छोड़ने के लिए करता हूँ जो तुरंत देखकर समझना मुश्किल हो
    • सिद्धांत में यह अच्छा है, लेकिन मुझे लगता है कि tool support के बिना ऐसे समझौते बेअसर हैं
      अगर team में काम कर रहे हों, तो और भी ज़्यादा
      इसका मतलब यह नहीं कि यह विचार बेकार है—मेरा कहना सिर्फ इतना है कि ऐसे tools होने चाहिए या बनाए जाने चाहिए
  • यह देखकर "perfect, good का दुश्मन है" वाली कहावत याद आती है
    इस तरह का technical debt या code smell वास्तव में और बेहतर तरीके से track/document/explain किया जाना चाहिए, लेकिन अगर आप JIRA जैसे productivity घटाने वाले काम पर ज़ोर देंगे, तो लोग उल्टा कुछ भी दर्ज नहीं करेंगे
    कम से कम code में TODO होने से वह कहीं न कहीं दर्ज तो रहता है
    TODO असल में "करने वाला काम" भी होता है, इसलिए उसका मतलब है
    • बड़े codebase में कई लोगों के TODO मिलकर चीज़ों को जटिल बना सकते हैं, लेकिन व्यक्तिगत project में यह एक अच्छा समझौता है
      "मुझे पता है इसे बेहतर किया जा सकता है, लेकिन उसके लिए मैं जानबूझकर अपना flow नहीं तोड़ना चाहता। यह functionality नहीं तोड़ता, बस हो तो थोड़ा बेहतर होगा।"
      editor में TODO highlight लौटकर दिखे, तो कभी-कभी उसे तुरंत निपटा देने में मदद मिलती है
      फिर भी ज़्यादातर TODO जीवन भर वहीं पड़े रहते हैं, या वास्तविकता में शायद ही कभी हल होते हैं
    • कभी-कभी code में ऐसा signal छोड़ना होता है कि यहाँ कुछ करना बाकी है, इसलिए TODO छोड़ देता हूँ
      चाहे JIRA हो, GH Issues हों या कुछ और, आखिरकार record का जुड़ाव होना चाहिए
      और अगर सिर्फ reference छोड़ दिया जाए, तो वह बाद में अपना अर्थ खो सकता है, इसलिए comment में explanation भी होना चाहिए
    • JIRA tickets AI से बनवाने वाला MCP server, जो Cursor से सीधे चलता है, ऐसा feature भी पहले से आ चुका है
    • मुझे लगता है कि इसे git commit message में छोड़ना कहीं बेहतर है
      बहुत सारे commits वास्तव में ठीक से नहीं बताते कि क्या बदला गया
      पुराने तरीके से TODO छोड़ने के बजाय, मैं चाहता हूँ कि बेहतर tools के उपयोग को बढ़ावा दिया जाए
      बहुत से developers बहुत कम commit करते हैं, और एक ही commit में कई काम भर देते हैं
      commit messages भी अक्सर "updating somefile.py" जैसी अर्थहीन चीज़ें होती हैं
  • यह style का मामला है। TODO को लेकर हर किसी की अलग definition या culture हो सकती है
    मेरे codebase में TODO का इस्तेमाल यहाँ बताए गए तरीके से होता है
    TODO implementation explanation के लिए है, खासकर जहाँ कुछ छूटा हुआ है उसे document करने के लिए—इसका मतलब ज़रूरी नहीं कि उसे करना ही है
    मेरे हिसाब से actual todo list को code में छोड़ना ज़्यादा मायने नहीं रखता। priorities बदलती रहती हैं, इसलिए जो लिखते समय महत्वपूर्ण था, वह बाद में उतना ज़रूरी न हो; और कोई अनदेखा issue बाद में असली प्राथमिकता बन सकता है
    केवल TODO comments अपडेट करने के लिए बार-बार PR नहीं उठाए जा सकते
    अगर कामों की सूची रखनी ही है, तो issue tracker या किसी ऐसे text document में रखना बेहतर है जिसे आसानी से update किया जा सके
  • शीर्षक थोड़ा clickbait है, लेकिन पूरी बात से मैं पूरी तरह सहमत हूँ
    अभी भी मैंने #TODO के रूप में एक बहुत दुर्लभ exceptional स्थिति दर्ज की है। 2 साल में वह कभी वास्तव में हुई नहीं, लेकिन बाद में अगर मुझे यह समझना हो कि मैंने उस हिस्से को क्यों handle नहीं किया, तो यह काम आएगा
    मैं उन लोगों की बात भी समझ सकता हूँ जो कहते हैं कि ऐसी चीज़ें बस comment होनी चाहिए। यह codebase की प्रकृति पर निर्भर करता है, और मेरे जैसे 2-व्यक्ति team के माहौल में TODO वाला तरीका अच्छी तरह काम करता है
    • हमारी team ने इस काम के लिए // TBD: [...] इस्तेमाल किया था। यह उन लोगों की नज़र से बचने की तरकीब थी जिन्हें TODO को लेकर एक तरह की बाध्यता रहती है
  • ऐसी जगह होना ज़रूरी है जहाँ ऐसे ज्ञात issues दर्ज किए जा सकें जिनकी value तो है, लेकिन tracking की ज़रूरत नहीं
    हो सकता है उन्हें सच में ठीक करने की कोई योजना न हो, लेकिन बाद में कभी समय मिलने पर यह जानने के लिए कि क्या इसे साफ़ किया जा सकता है, कम से कम एक बार ctrl-F से खोजने लायक तो हों
    मुझे लगता है बहुत सारे tools और process TODO को code smell मानते हैं, और यह अनुचित है
    • मैंने व्यक्तिगत रूप से अभी तक ऐसा issue अनुभव नहीं किया है
      यह अंततः priority का मामला है, और मुझे यह टूटी खिड़की वाले सिद्धांत (Pragmatic Programmer की मशहूर उपमा) जैसा लगता है
      अगर सच में तय है कि इसे ठीक नहीं करना, तो इसे software documentation में दर्ज करना बेहतर है
  • लेख में दिया गया यह उदाहरण

    // TODO: If the user triple-clicks this button, the click handler errors because [xyz]
    मुझे वास्तविक TODO से ज़्यादा एक साधारण comment जैसा लगता है
    इस तरह के explanatory comments निश्चित रूप से मददगार हैं, लेकिन इन्हें TODO कहना थोड़ा अजीब है
    TODO तो वह होना चाहिए जहाँ वास्तव में किए जाने वाले काम का स्वरूप साफ़ हो, जैसे "यह function XYZ के अनुसार अलग value लौटाना चाहिए"
    इस अर्थ में TODO को code में दबा हुआ नहीं होना चाहिए, बल्कि issue tracker में होना चाहिए
    मेरे अनुभव में TODO अक्सर सिर्फ PR approval की जल्दी में code quality से समझौता करने को जायज़ ठहराने का तरीका होता है। वास्तव में वे शायद ही कभी पूरे होते हैं, और बस यह भावना छोड़ जाते हैं कि "कभी समय मिला तो कोई जूनियर developer इसे ठीक कर देगा"

    • comments का काम यह समझाना है कि यह code इस तरह क्यों काम कर रहा है
      उदाहरण के लिए अगर सिर्फ
      // If the user triple-clicks this button, the click handler errors because [xyz]
      इतना लिखा हो, तो यह साफ़ नहीं होता कि यह bug है या मूल इरादा
      TODO एक छोटा-सा signal है: "यहाँ कुछ अपूर्ण है, काम करते समय ध्यान रखना"
      अगर यह ऐसा काम है जिसे ज़रूर हल करना है, तो कहीं और track करना सही है
      लेकिन अगर TODO को ही कम करने लगें, तो मेरे हिसाब से नतीजा सिर्फ यह होगा कि undocumented code बढ़ जाएगा
    • ऊपर वाला उदाहरण मुझे कोई खास अच्छा TODO comment नहीं लगता
      उतने समय में तो उस bug को सीधे ठीक कर दो, या फिर "triple click को [xyz] की वजह से ignore किया जाता है" जैसा comment छोड़ do
      अगर trigger और root cause दोनों पता चल चुके हैं, तो मेरे हिसाब से 80% काम तो पहले ही हो चुका है
    • इसे "skip" की तरह समझा जा सकता है। कई बार इसे करना ही ज़रूरी नहीं होता
      समस्या तब होती है जब code पूरी तरह सही काम नहीं कर रहा हो, लेकिन उसे ऐसा मान लिया जाए
      मेरे द्वारा देखे गए सबसे अच्छे TODO में से एक था "TODO: encrypt this", जहाँ security code में साफ़ लिखा था कि encryption नहीं हुई है
      इसी वजह से कोई भी तुरंत समझ सकता था कि code encrypt नहीं किया गया है, और यह भ्रम भी कम होता था कि कहीं modularization के कारण encryption कहीं और तो नहीं हो रही, या फिर दोबारा encrypt करने की चिंता करनी पड़े
    • दिया गया उदाहरण TODO से ज़्यादा FIXME के क़रीब है
      यह स्पष्ट रूप से एक error है, लेकिन उसे ठीक करने की तात्कालिकता कम है
  • मैं इससे काफ़ी असहमत हूँ
    या तो इसे bug के रूप में दर्ज करो, या अगर वास्तव में उस पर काम नहीं करना है तो TODO मत छोड़ो
    // TODO: If the user triple-clicks this button, the click handler errors because [xyz]
    यह सिर्फ observed behavior का रिकॉर्ड है। यहाँ TODO शब्द नहीं होना चाहिए
  • मैं भी इसे परतों में इस्तेमाल करता हूँ
    FIXME तब इस्तेमाल करता हूँ जब उसे ज़रूर ठीक करना हो, या अगला कदम साफ़ दिख रहा हो
    TODO उससे थोड़ा ज़्यादा धुंधले विचारों के लिए होता है, या सिर्फ इसलिए कि बात दिमाग़ से बाहर निकल जाए और मैं अगले काम पर ध्यान दे सकूँ
    कई स्थितियाँ हो सकती हैं—जैसे idea अभी पूरी तरह पका न हो, यह यक़ीन न हो कि इसे सच में करना चाहिए, या किसी संबंधित चीज़ का इंतज़ार हो
    अगर उसे लिखकर न रखूँ तो वही बात दिमाग़ में घूमती रहती है, लेकिन TODO या कुछ भी लिख देने से मानसिक रूप से काफ़ी हल्का महसूस होता है
  • मैं comments को अक्सर code लिखने की क्षमता की कमी के संकेत की तरह देखता हूँ
    अच्छा हो अगर code इतना साफ़ लिखा जा सके कि comment की ज़रूरत ही न पड़े
    फिर भी, अगर बाद में खुद मुझे भी पढ़कर समझ न आए, तो मजबूरी में comment लिखता हूँ
    दुख की बात यह है कि अगर बाद में कोई code बदल दे और comment अपडेट न करे, तो उल्टा और ज़्यादा भ्रम पैदा होता है
    मेरे हिसाब से TODO committed code में नहीं होने चाहिए; उन्हें project या issue management system में manage किया जाना चाहिए