Developers = Crazy individuals with mild OCD.
Individuals who are particular about their operating system, the editor they use, the way they use language constructs.
In this post, I am going to talk about how this craziness make code reviews even crazier. A real pain in the 🍑
Imagine 10 such individuals working on a project, everybody having their own set of preferences.
- Some prefer curly braces inline, some on next line.
- Some prefer a space before their if parenthesis and some don't.
- Some prefer space before and after their logical operations, some want them to be as compact as possible.
- You get the point..
As a reviewer, this is what you might end up seeing during code reviews. Where the hell is the actual code change? Also in my head -> BC 🤬 ???
While I have never played Waldo, I have seen memes on the internet, and it was the first thing that came to my mind when I got my first "crazy" pull request to review
Having consistent coding styles within a team is critical, every developer in the team should agree to use the language features the same way and that would make a reviewers life so much easy. But how do you enforce this? We'll take a look at that in our next section.
If you are still trying to figure what the code change was, here it is
Which again, does not make any sense,
i++ within the context of a
for loop is the same.
How do we enforce code consistency?
This sleek little configuration file helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs.
😋 The best parts
- Works with a
wide range of file types.
- These settings
take precedence over your editor settings, which means that you can enforce consistent coding styles for your code base, settings that are specific to a repository.
🧱 To create one (I am going to use Visual Studio since that's my preferred IDE, your favorite IDE should have similar steps)
All you have to do is right click on your project solution and add a new editorconfig This will pick all the editor settings you have in your Visual Studio instance and put it into a .editorconfig file inside your codebase. You can now push this to your remote repository. You should also get in touch with your fellow developers and make sure all are in agreement with the settings in place. As soon as they pull this file to their local, their preferences will be overridden.
You could also go to Github, search for .editorconfig and take a look at how others have them created in their repositories.
😩 Caveat in Visual Studio
Editorconfig settings are
not used automatically in Visual Studio, you will have to execute code cleanup each time. You could install
extensions which would run
code cleanup on
save operation to overcome this. In my opinion Microsoft should make this a default behavior.
Editorconfig has made code reviews much more simpler for me and my team, makes it much more bearable now 😜, highly recommended.
Thank you for going through this post. I hope you found it useful. Cheers!