Question

I scratched my head for two weeks trying to compute something based a variable.

It turns out I set the variable earlier to solve temporarily another problem and never went back to correct it.

Normally, I try to mark up code with //ToDo ‘s to remind me to remove the temporary variable.

In this case, I didn’t mark it since I was skipping around trying to fix more than a few things. (I couldn’t figure out what was going on so I was trying all sorts of stuff!)

How do you mark temporary variables that you wish to remove later?

1. Do you instantiate them as private at the top of the class?
2. Mark them inline with something like //Delete Me Later

What’s is the best practice for marking variables that you need to delete later?

(short of having a really organized brain of course…)

Answer 1

Instead of commenting to every single idea / recommendation, I thought I would answer and then have you vote on this answer.

First, thank you very much for sharing your processes and ideas. I really appreciate it.

I think there are a number of factors in play that should be driven by the desire to avoid making stupid mistakes or suffering from ones you have already made. I made one (of many.)

Let’s just assume that version control and team reviews trump all; however beyond version control (assuming that you committed crappola to your good code):

• @Deprecated is very good. It seems to glare at you. We all need glaring. Hopefully we can see the forest through the trees.

• To me, diffs are onerous since I frequently make sweeping changes but it is a great suggestion that works in many cases.

Some notable things:

Since I am usually sole developer, I rely on ToDos. They’re easy to use. I have an informal rating system with the todos. For example, something that really needs to be cleaned up looks like this:

//TODO * Might be a future crash here // where one star is something I really have to clean up before I ship. 
//TODO *** Can some lines be trimmed from this view adapter?

Multiple stars are arbitrary and perhaps even optional. I keep cycling through them. @BriGuy37 – that was an interesting thought. @Sriram – that was interesting too – setting up tags under certain conditions.

In my case, I didn’t dox the //TODO and it burned me.

Biggest rule perhaps out of all of this is:

Unitize your work in a manner that you don’t make stupid errors like this. Know what changes you’re making and when. Keep calm.

Thanks again! It’s great to pick up best practices from the community to incorporate in your work!