loading...

re: TODO in code VIEW POST

FULL DISCUSSION
 

I think it depends on where the code is headed and whose eyes it's for. Yours? Leave them in, as long as it doesn't start to get crazy. What I usually do is I have my Markdown file with the longer-term things or overall goals that don't tie in directly to lines of code, and I move things in and out of there as they become more relevant/less relevant. For things that are much shorter-term, ie, // TODO: fix the alignment here or // TODO: figure out what the hell is happening, I leave those inline. Both of those are ones I'd take out of something I was handing in (student still) or showing as a portfolio thing.

I feel like it's just fine to leave in things that are ideas or TODOs that are more embellishment or realizing something isn't ideal but does work, because it shows some of your process--as long as it doesn't get too much, and you aren't passing this on to others who are going to need to slog through them. Something like TODO: pull this into its own method etc.

But for anything that final, which hopefully there are fewer TODOs in anyways, I would just keep a set/branch that has the TODOs in it, and remove them programmatically (regexes, awwwww yeah) for the final unless it's something another person is receiving and needs to do as a task.

 

I really like this. This is basically what I do when I'm on a feature branch with intermediate commits, then part of my process for merging to master is filtering out the TODOs and making sure they're gone.

Code of Conduct Report abuse