Hacker News Reader

Comment by atsjie | Hacker News Reader

We stopped some devs in our project from adding too may TODOs and FIXMEs.

For good reason; the more TODOs and FIXMEs a codebase contains, the less impactfull they are. We had so many TODOs no-one every batted an eye when seeing them, and they never got fixed. It just made you feel bad.

Also a lot of TODO's expressed opinions about the "ideal" scenario, but in practice most of those TODOs were for code that was "fine" or "good enough". In those scenarios it's better to omit the TODO/FIXME keyword and just describe the design decision that was made.

View on HN

Despite their name, i think TODOs should not be treated like tasks to complete, you should not let them make you feel bad. Instead, they are kind of a shorthand documentation of what's going on in an implementors mind, what extensions did they think of? Where did they feel improvements could be made? When changing or rewriting the code, these thoughts can be considered.

Oh, this smells…

If you have mostly "fine" and "good enough" code I fully understand why people want to put TODOs and FIXMEs everywhere; as the code is likely a technical debt catastrophe all over the place. (Because that's the usually meaning behind wording like "good enough".)

If nothing of this got ever fixed this means the devs never got time to do that. Just the next red flag…

If a manager would tell me I shouldn't put TODOs / FIXMEs into the code I would be on my way out pretty quickly. As this means they constantly produce tech dept but actually want to hide this fact.

It's just as likely that it's "TODO: add handling for this case which is out of scope during design and which no user is likely to ever request, because the developer argued that it should be there and got shot down"

Disagree, but this maybe stems from different interpretations of those keywords. Too often seen, and similar often in the aftermath realized myself placing TODOs at places that really were just good enough, bug-free, served all business needs, and mostly could have been a MAYBE or NICE2HAVE (if not totally omitted, because just distracting and not relevant).

Often however those ideas are also wrong perfectionalism and can lead to more bug potential or complexity to understand, like trying to create the perfect abstraction while you only have n=1 use cases, especially the younger devs are prone of. (Or one dev believing this part should be written like that and that, while 5 other devs would disagree, that's the best.)

TODOs should be really for stuff that is still missing and needed, because of a requirement or some real ugly workaround taken and tech debt created, and not just because a dev has feelings about some code. Similar FIXME also only for really broken stuff or corner cases one for whatever reason cannot fix right now..

> If a manager would tell me I shouldn't put TODOs / FIXMEs into the code I would be on my way out pretty quickly. As this means they constantly produce tech dept but actually want to hide this fact.

Noone said that (just not too many), it is not black and white. Often what one sees as tech debt is only wrong perfectionalism, that in the end doesn't help. If you need to place TODOs and FIXMEs often, then why not do them right now? If they are really necessary and you need to put them often like once a day, then actually I would question the place.

Placing TODOs and FIXMEs is right where necessary, but please not once a day for something that maybe could just be done better.

I btw like the "No TODO without a ticket" rules, they help with this problem automatically :)

A TODO means you have identified a way to make the code better. Since not everything needs to be at the highest quality, it is helpful to say what will benefit from being improved for future programmers.

If the TODO is not really "to do" before release, I change the name to: PERF (performance), MAYDO (nice to have) or FUTURE. If it doesn't break the user's story then it's not a real "to do".

I also leave comments for obvious good ideas that don't work, in case someone has the same idea later.

TODOs are nicely indexed and collected by major IDE linters/code analyzers. Not sure if these alternatives are.

The implication that a TODO is a bad thing is wrong. A TODO is an opportunity for refactor. Yeah the code 'works' today, but it could be improved. A TODO means there was a blocker (in my experience: time).

Reply on news.ycombinator.com