All else being equal, it's obviously better to have good and complete code over bad or incomplete one. But in real life, all else is rarely equal. The ideal code may need additional design and weeks of coding, or it may depend on something someone else should be doing and it'll be quite a while before they can do it - but your code needs to get in ASAP because you are halting development for everyone else and/or making all the integration tests fail on something trivial before they can get to the code they are actually supposed to test.
So, pragmatically, this is something you sometimes have to do. The second concern remains - are TODOs and FIXMEs the right way to do this?
Most of the opinions I've seen here - both in favor and against - seem to use a concept of "TODO as my bug tracker". The opposers claim that TODO is a terrible bug tracker and the "tickets" will just get lost. The supporters reply that proper tooling can help you manage the all the TODOs, and that having the "ticket" bundled with the code it refers to is an advantage both when creating and tending to it.
I, on the other hand, want to argue that TODO is not a bug tracker.
The things you mark with TODO/FIXME are not high priority. They are certainly not as high a priority as the code you had to commit even with TODOs and FIXMEs, and since the code does, somehow, works and functions, they tend to get lower priority than code that doesn't work and functionality that needs to be implemented.
So, even if, in addition to the TODO, you open a ticket in the actual bug tracker - you should not expect to get around to doing it that soon.
So, the ticket will remain unattended in the tracker, but the TODO comment could still be encountered!
Alice needs to refactor/fix/add functionality, and sees some weird code. She doesn't quite understand why it's there - "who is the imbecile that wrote it?". That imbecile may as well be Alice, because she hadn't recently touched that code, but even if it's Bob, he may not be able to answer - because maybe he hadn't touched that code recently.
But - if that code had a TODO, explaining that it can be removed once the foobar bug is fixed - Alice doesn't even need to ask Bob. She knows the foobar bug was already fixed, and she now knows what's the meaning of that weird code - so she can safely remove it.
Note that that TODO is meant to be outdated - Bob was expecting people to encounter it after the foobar bug was fixed. He just couldn't get to it himself, because that code was not actually harmful and he had much more pressing things to do.
So - TODO is not a bug tracker. You are not meant to get a list of TODOs, and prioritize them. It's a comment - it's meant to explain why the code looks that way and give you context if you want to change it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There are two concerns here:
master.TODO/FIXMEto label that code.All else being equal, it's obviously better to have good and complete code over bad or incomplete one. But in real life, all else is rarely equal. The ideal code may need additional design and weeks of coding, or it may depend on something someone else should be doing and it'll be quite a while before they can do it - but your code needs to get in ASAP because you are halting development for everyone else and/or making all the integration tests fail on something trivial before they can get to the code they are actually supposed to test.
So, pragmatically, this is something you sometimes have to do. The second concern remains - are
TODOs andFIXMEs the right way to do this?Most of the opinions I've seen here - both in favor and against - seem to use a concept of "TODO as my bug tracker". The opposers claim that TODO is a terrible bug tracker and the "tickets" will just get lost. The supporters reply that proper tooling can help you manage the all the TODOs, and that having the "ticket" bundled with the code it refers to is an advantage both when creating and tending to it.
I, on the other hand, want to argue that TODO is not a bug tracker.
The things you mark with
TODO/FIXMEare not high priority. They are certainly not as high a priority as the code you had to commit even withTODOs andFIXMEs, and since the code does, somehow, works and functions, they tend to get lower priority than code that doesn't work and functionality that needs to be implemented.So, even if, in addition to the
TODO, you open a ticket in the actual bug tracker - you should not expect to get around to doing it that soon.So, the ticket will remain unattended in the tracker, but the
TODOcomment could still be encountered!Alice needs to refactor/fix/add functionality, and sees some weird code. She doesn't quite understand why it's there - "who is the imbecile that wrote it?". That imbecile may as well be Alice, because she hadn't recently touched that code, but even if it's Bob, he may not be able to answer - because maybe he hadn't touched that code recently.
But - if that code had a
TODO, explaining that it can be removed once the foobar bug is fixed - Alice doesn't even need to ask Bob. She knows the foobar bug was already fixed, and she now knows what's the meaning of that weird code - so she can safely remove it.Note that that
TODOis meant to be outdated - Bob was expecting people to encounter it after the foobar bug was fixed. He just couldn't get to it himself, because that code was not actually harmful and he had much more pressing things to do.So - TODO is not a bug tracker. You are not meant to get a list of TODOs, and prioritize them. It's a comment - it's meant to explain why the code looks that way and give you context if you want to change it.