[mpolichette]

If you don’t fix it… and the code is working… what is the problem?

I leave notes like that sometime as indicators of intention… or invitation to the next reader… but if it never changes and is not causing issues… that’s fine, leave it as is.

[josephg]

Your code is like a home. If your home is messy, it changes how you feel in the space. If my home is messy I feel weirdly ineffective and sloppy. Tidying up makes me feel empowered and capable.

Don't leave mess alone. Tidy it up. A codebase you actively nurture will make you feel like change is easy. Its well worth the time investment.

[tgsovlerkhgsel]

On the other hand, if you spend all your time tidying and cleaning, you never get anything done.

There is such a thing as "too tidy", and while everyone disagrees on where the point is, companies tend to be very good at forcing that point through constrained resources.

[mazuhl]

And the best way to manage your home is to separate the tasks into tidying, organising and cleaning. 3 separate and distinct actions. The same applies to code and projects.

[simplotek]

> If you don’t fix it… and the code is working… what is the problem?

Because most of the time your hack only works by accident, or doesn't handle expected corner cases, or leaves out important use cases, or is a ticking time bomb.

[hamburglar]

If you’re regularly encountering or writing code that only works by accident or doesn’t handle important use cases, it isn’t the fault of a TODO. A TODO should document something that has been considered and would potentially be an improvement, but is not currently necessary. It isn’t supposed to be a flag that says “warning: I’m checking in broken code.” If the accompanying code is actually deficient, reject the PR.

[drewcoo]

"born in a house with the television always on"

That's a Talking Heads lyric and not a point of fact.

[quietbritishjim]

> If you don’t fix it… and the code is working… what is the problem?

Two obvious problems: (1) more likely future bugs; (2) wasted time

Often "fix it later" means "de-duplicate this copy and pasted code later", where the copy is slightly different so there's some refactoring required to do that.

The future bugs come from changing one copy but forgetting to change the other. Sounds unlikely but very common in practice.

The wasted time comes from having to redundantly update both (or several!) copies. That's more work than it sounds because you have to understand the subtle differences in each, whereas if you had refactored them into one code base then the differences would be some obvious function/class/etc. Of course, each time, this update to all the copies is less effort than doing the refactoring, so the wasted time builds up gradually over time.

[mopsi]

> If you don’t fix it… and the code is working… what is the problem?

It may be very inefficient, for example. Works now, but may unintuitively slow down when dealing with workloads that looked very far-fetched at the time.

I have inherited a really nice C++ codebase from 1980s that contains warnings for Year 2038 problem and all sorts of other potential issues, and I can't thank those engineers enough. So many times I've dug into a problem or started implementing a new feature only to discover that someone had already thought of that and left useful pointers in comments.

Whatever version control or note-taking applications they might've used instead, I doubt I could even run or open their files 30+ years later.

[philipwhiuk]

Sounds like there's no problem with //TODO: Fix later then if it's actively helping you.