Old projects (maybe even 6 months or less) often come without test suites, are tightly coupled with an outdated version of a framework (if not: has lots of boilerplate code), and are written without consistency in code style.
When working on such a project, it’s tempting to start moving brackets around, replacing old syntax style with newer language version syntax, and renaming variables/classes/functions. Especially when you’re refactoring or adding a feature.
With this blog post I wanted to share some tips and pitfalls on code style changes in legacy projects.
First of all: fixing code style isn’t necessarily a bad thing.
Code style makes code more readable, less personal, and more uniform.
As long as there is some kind of agreement that you will be working on this project for at least the next few months,
your future self and colleagues might benefit from a better code style.
You might be tempted to use an automated tool to reformat an entire file, or even your entire code base.
Here’s why that’s not a good idea:
It is a good idea to setup a CS fixer for newly created files though.
You can gradually build up a namespace full of new
classes that adhere to a certain code style standard and have it backed by an automated tool.
While refactoring you can slim down existing classes and functions and inject new, well tested dependencies.
That way you can slowly move away from the legacy code that’s still badly formatted.
If you do want to reformat an entire directory of code, despite my advise,
make sure to have as few branches and open pull requests as possible. Ideally: no pull request and only one branch.
Then do a single commit where you only reformat the code, nothing else. Push it, and done!
Happy CS fixing!