Let’s talk about questionable code and the best practices to fix it. Even if you’ve been a developer for years it’s good to do a quick review once in a while and make sure you haven’t picked up any bad habits.

Commenting out code instead of deleting it

I’m as guilty of this as anyone else, but honestly it’s a waste of time. If you ever actually need that code back you can pull it out of source control, that is what it’s for. As much as I’ve wanted to hedge my bets and just comment out that block so it’s easier to put it back if I need it again, I’ve almost never actually needed to do that. The commented out code just hangs around in your file forever, confusing new developers and forcing you to wonder if you should update it every time you work on that method. That’s a lot of trouble to go through over code you’re never going to use again. Just delete it, it’s easier. If you’re really worried about getting it back, put the delete in its commit and add a good descriptive commit message.

Cryptic variable names

This is a huge pet peeve of mine. Characters aren’t rationed! You can use as many as you need to make the purpose of your variable clear, nobody’s going to come and take them away. Excessively long names are annoying too, but they’re not nearly as bad as wasting time figuring out that “un” actually means user name. Autocomplete has been around for a long time, the excuse of not wanting to type long variable names is not going to fly. Give your variables meaningful names, the inconvenience will pay off in the long run.

Long methods

Again, there’s no rationing! You do not need to stuff everything and the kitchen sink into one method, you’re allowed to have more than one. Refactoring has been around for a long time too, any reasonable IDE should let you extract a method in a few clicks. Even if you have to manually refactor, the pain is worth it. With smaller well named methods, you can quickly skim through code and figure out what’s going on. Without them, you can waste a whole lot of time trying to figure out which part of that ginormous method you actually need to change.

Methods with huge numbers of parameters

This issue is closely related to the last one. If your method has an excessive number of parameters, it’s probably doing too much and it’s likely too long as well. This one can be painful to fix depending on the rest of your architecture, but if you can manage it without tearing everything apart it’ll make things much easier the next time you need to look at that code or use that method. The more parameters you have, the more changes you have to mix some of them up and introduce weird bugs into your code. If you really do need lots of parameters, at least bundle them up in a <your method>Config object to make it harder to mix them up.

These are far from the only problems you’ll see in your code, but looking out for these simple issues is a good place to start cleaning up your codebase.