Skip to main content
18 events
when toggle format what by license comment
Jun 23, 2022 at 22:27 comment added Phil1970 Speaking of TODO comment, I often use a variation like TODO_PRINT_MODULE, #ifdef OBSOLETE_PRINT_MODULE when doing major changes for a somewhat large features (a few weeks of work). One benefit, is that you can put those comment when you see something that need to be fixed but you don't want to do it right now.
Jun 23, 2022 at 16:03 comment added Kenny Evitt @Tadeo I invested a little time figuring out how to use find and grep to write some handy little shell scripts for doing various kinds of 'text searches' (and also do nice things like, e.g. exclude 'build' directories from the 'search candidates'), but extensions can work great too!
Jun 23, 2022 at 16:01 comment added Kenny Evitt @DavidMårtensson Yup!
Jun 23, 2022 at 14:20 comment added David Mårtensson As said about TODO's, if they do not get fixed, its because they does not create enough problems to get fixed, which for the method of quick and dirty means, does not need fixing. But having the TODO also means than next time you poke there you at least know about it, and can decide if the new feature NEEDs this or even solves the TODO :)
Jun 23, 2022 at 0:00 comment added Tadeo @KennyEvitt you can find extensions for your IDE that do exactly that. In fact I've installed one after reading your comment. Thanks!
Jun 22, 2022 at 14:34 comment added Kenny Evitt A command/script to find and list all of your TODO comments is also very helpful!
Jun 8, 2022 at 16:56 comment added Doc Brown ... and I would like to add that the described process is simply the application of the YAGNI (yet!) principle.
Jun 8, 2022 at 16:54 comment added Doc Brown This is indeed good advice. Instead of a TODO comment (and depending on the level of abstraction the of the topic) one could also add a low or medium priority ticket in the team's issue tracker for the part of the task one cannot solve immediately, or add an entry into the backlog, if the team works in a scrum-like way. That avoids tons of TODOs in the code.
Apr 16, 2022 at 22:15 comment added laike9m @xehpuk If you always link TODO with a bug, then use proper ways to prioritize/resolve bugs, you're good. The leftover TODOs are mostly of low importance.
Apr 16, 2022 at 22:14 comment added laike9m +1 to the idea of "It's amazing how a few days of background thought can clarify a vexing problem"
Apr 11, 2022 at 17:14 comment added corsiKa @LauriHarpf I haven't seen them where you get sprint time allocated to it, but I have certainly seen it where it's taken into consideration when planning something.
Apr 11, 2022 at 15:08 comment added Doc Brown @LauriHarpf: actually the only TODO comments which you find in an old codebase are the ones noone cares to fix. The ones which were fixed are usually deleted from the code, so you don't find them except in the VCS.
Apr 11, 2022 at 9:43 comment added xehpuk This leads to 10+ year old TODOs scattered throughout the codebase.
Apr 11, 2022 at 8:37 comment added Lauri Harpf I haven't seen a project where the TODO comments are actually fixed later
Apr 10, 2022 at 23:42 comment added Drake P I second the TODO notation. Other good options are FIXME for known issues (e.g. "FIXME this code breaks if this edge case occurs") and XXX for "dirty" code (e.g. "XXX this is inefficient because xyz, but it gets the job done"). I also sometimes use NOTE for warnings or explanations to future devs, though I've only sometimes seen syntax highlighters recognize this one. Leave breadcrumbs for resolving the technical debt you make.
Apr 10, 2022 at 9:34 history edited Benjamin Gruenbaum CC BY-SA 4.0
edited body
Apr 9, 2022 at 7:22 comment added Alex R The "TODO comment" can be a great accelerator if you use it not only for "obscure edge cases" but really any piece of functionality that you can get away with postponing because no one's pinging you on Slack asking about it right NOW
Apr 8, 2022 at 16:29 history answered user949300 CC BY-SA 4.0