91–100 of 301 posts
I use TODO in my code all the time as shorthand for: "This code is functional, but if you are going to do another iteration you may want to consider the following improvement or optimization." It's not at all meant to be to be like an item in a TODO list. Code would be a terrible place to keep that.
Use IMPROVEME instead of FIXME ;)
Earlier quoted context omitted.
Sure, for the individual. Does the project track them internally? How are they followed up on? How is work assigned and prioritized?
When the file is next edited by the next individual. They don't need to be tracked
Earlier quoted context omitted.
What's the advantage of throwing away context that could be useful in the future? I've taken ownership of codebases with technical debt before, and when modifying the code for something time-sensitive, I often annotate issues with the code whose solutions (usually refactoring) can't be fit into the timeline of the current project. I (or others) can then take advantage of these annotations when I have time to dedicate…
You don't throw it away, you put it in the issue tracker where it can be prioritized, tracked and categorized. If it's not worth of the issue tracker, it shouldn't be worth of a TODO either.
Earlier quoted context omitted.
Correct me if I'm wrong but I use "FIXME" for this intent. I keep TODO for stuff actually left to implement.
Is there a standard for valid flags? I recently recommended a client use `TODOSECURITY` for todos which had security implications until fixed - I discovered functionality which was implemented before authorisation had been developed, resulting in a codepath which was unintentionally reachable by standard users. Seemed weird to make up a codeword but I wasn't aware of any standard convention, and visually highlighting…
I use this pattern across my codebase for the "critical functionality missing" scenario: #if DEBUG #define TODO(msg) #else #define TODO(msg) #error msg #endif Works like a charm. I've got another PRERELEASE() macro that lets you do an unofficial preview build, but would break an official stable release.
#if DEBUG
#define TODO(msg) #warning msg
#else
#define TODO(msg) #error msg
#endif1 is immediate, meaning it needs to be fixed for the system to work.
2 is something that should be done before release.
3 is a near term wish list sort of thing, and
4 is a hopeful, probably never sort of thing
In addition, another place I deviate from the norm is when I comment out code, I write the reason why it's commented out.
These two things really help keep my code from becoming incomprehensible as time passes.
I use this pattern across my codebase for the "critical functionality missing" scenario: #if DEBUG #define TODO(msg) #else #define TODO(msg) #error msg #endif Works like a charm. I've got another PRERELEASE() macro that lets you do an unofficial preview build, but would break an official stable release.
#ifdef NDEBUG
#define assert(condition) ((void)0)
#else
#define assert(condition) /*implementation defined*/
#endif
...
assert(("There are five lights", 2 + 2 == 5));
...
test: test.cc:10: int main(): Assertion `((void)"There are five lights", 2+2==5)' failed.
I use TODO in my code all the time as shorthand for: "This code is functional, but if you are going to do another iteration you may want to consider the following improvement or optimization." It's not at all meant to be to be like an item in a TODO list. Code would be a terrible place to keep that.
The more essential the change/fix, the more hashes. Made it really easy to do a global search for them, and you could easily filter the results to only show the most important ones by searching for longer strings of hashes.
Twenty years later and I’m still doing that in my personal projects.