Here’s a quick guide on cleaning up your codebase:
Work In Modules
When you first sit down to start cleaning up, it’s going to feel overwhelming. It’s difficult to decide where to start. The simple answer is, at the top. Start with the first file and work your way down.
In each file, it can be helpful to temporarily add some returns in to make it easier to see where one block of code ends and another begins. This will also prevent you from accidentally deleting something you needed.
Delete, Don’t Comment
Some devs are guilty of what I call method hoarding. Remember that awful code you wrote three months ago, for a legacy version of the app, that no longer does anything and is utterly useless?
Yeah, you don’t need that anymore.
There’s no need to comment it out if you know there’s no need for it. Just get rid of it. If you really want to save it, create a graveyard file outside of the working directory where you can save all your old code. Be sure to notate what file it originated from, what it’s use was, and when it was removed.
Test Often
Editing code is not the same as editing english. It’s easy to remove something important without even realizing it. Every time you finish a file or make a big change,
Testing the code that pertains to that. Unit tests are best, but if you don’t have those then manual testing will suffice.
Follow the Style Guide/Stay Consistent
Pretty much all major languages have a standard style guide. Google it and use it. It will save a lot of time and rescue you from having to make tough styling choices. Plus, if you bring on another dev to look at your code, it will be much more familiar to them and they will already know how to style it (assuming they are a good developer and know the style guide).
The key with style guides is to stay consistent. If you run into a situation not covered by the style guide for whatever reason, document it and keep the styling consistent across all other instances.
You should also have a layout for file naming, file structure, git commits, and pull requests. Document all of that and again, stay consistent!
Cleaning Is Not Refactoring
Don’t refactor while you’re cleaning. Refactor while you’re refactoring!
Cleaning the codebase is purely stylistic. It’s making your code easier to read relative to the way it’s laid out in the IDE. While this is also an affect of refactoring, the goal of refactoring is to make your code more efficient, which has nothing to do with cleaning.
This also means you can’t rename things. Renaming things in your code is an extremely risk game, especially if you have a large codebase. Do your best to get the name right the first time. If there’s a name that’s really bothering you, put it in the backlog until you realize you’ll never have time to fix it and eventually accept it as an ugly quirk of your code (which you can later use as a topic to bitch about when you’re having beers with your coworkers).