Always, although I never use TODO for fixes or for hacks (never even used the HACKED task), in fact all I use TODO for is for future additions to the project that I want but don't have time to implement yet. For fixes / hack checking isn't that best done through unit tests and have full code coverage of the area, at least that way it would always fail until you fix it and you can apply the assertion checks globally too if necessary as a fix in one area could just give birth to a bug in another.

Edit: Ofc this isn't always the easiest way to test graphics / sound / scene logic issues but then sticking a TODO flag may not be the most efficient method either, well not for me at least anyway

Code can pass any and all unit tests you could write, but still be in dire need of fixing/improvement. Performance issues, working well with future expansion, etc. Lots of reasons to still maintain a ToDo list along side other things.

I agree, I am not saying TODOs are bad I am just saying I never use them for 'fixing' stuff or for anything important for that matter, for extending projects they are great, things typically not part of the project gantt (which is directly connected to my code work items via TFS) but could be a great addition, a wish list I guess. I think my post may have made it look like task lists in general are bad, this isn't the case, im not sure how other version controls work or how others manage but for me it is VERY important for me to ermm analyse, schedule my project work outside code if that makes sense. TFS and ofc VS have some excellent ways to do this, so I cant really use TODO for anything other than a unexpected wish list I guess.

I don't think this is an uncommon way of doing things either, as these are all built in features.

That code looks pretty dodgy to me.

I should actually use &str[0] to get a non-const pointer to the internal data... oops. That'll let me avoid the const_cast, but it'll do the same thing anyway. Really, they ought to just make .data() return a non-const pointer.

Hmmm, come to think of it, &str[0] also ensures that compiler implementations doing clever things behind the scenes like copy-on-write strings handle the situation correctly. GCC iirc, still uses COW for relatively recent versions of the compiler. C++11 requires std::string to not be COW, but last I heard GCC hadn't yet changed their std::string implementation. So my const_cast actually could be buggy.

I still think .data() ought to return a non-const pointer.

and you have close to a normal distribution now...

Always.

I always reread and reread my code. This is my typical workflow:

Write -> Test -> Read -> Write -> Read -> Test -> Read -> Test -> Read -> Write -> Read -> Test -> Read -> Test -> Read -> Commit -> Read -> Read -> Refactor -> Test -> Read -> Refactor -> Read... and so on

those TODOs won't survive the endless rereads.

I can't move forward with code until my current solution is to my satisfaction. I've iterated on code for a week or more on personal projects verifying a design. I'll get done with it and more often than not decide on a cleaner design or algorithm. There are no TODO comments. I makes my coding very slow, but it's code I'll go back and look at later and reuse.

It's interesting at work I have to maintain and fix bugs. I don't know how to put it nicely, but it's horribly designed and prone to error with >50% comments or commented out code where most of the comments don't match what the code does. (Not the new projects, but old ones). It's weird seeing the difference in coding styles. I ran into one part while fixing a bug where a previous developer had copy and pasted some code in like 10 places and made a change to like 3 of them and forgot the rest leading to very weird behavior. My favorite one the other day was "// Does this even work?" while looking for a bug my breakpoint lands on that. "no is the answer, are you kidding me?" Good times. The code is filled with TODO statements and it wasn't really written in a rush.