Conforming to an established code style

Recently I was doing a quick pre-pull request code review for a project I had filed a bug report with. The person contributing the fix (who was not the developer of the project) admitted he was not that experienced with the overarching code, so I left a few comments on his changes in an attempt to help him out. While doing this, I saw the entire script had been reformatted. Naturally I inquired why, as it was not part of the required and requested changes. It turned out to be a beautifier that runs on save, and he had forgotten to turn it off.

This short experience got me thinking about code styles, what an author or team prefers, and what is used in the code. A code style is not arbitrarily chosen. Rather, it develops over time as a programmer writes code. They discover a certain level and character of indentation they like, the location of key symbols, and a naming system that works best for them. Sometimes the code style is dictated not by preference but by how it is already written. Such a situation can occur when a project is inherited or when contributing to an outside project.

That is why it is important to conform to an established code style. A programmer and/or team has specifically chosen that particular style, white space and all. It is irresponsible and unfriendly of a fellow programmer to wipe out an established formatting just because it does not fit into their style. Many projects perform code style checks when reviewing contributions to ensure the changes match the code base. If you are asked to make a style change that may not fit into your preference, do so without complaining and rebuttal, and things will go better for you.

From one programmer to another, even if you are just starting out, please turn off your beautifier, respond kindly to requested changes, and submit to established code styles when you are working on a project that you may not have personally overseen or directed. Programmers are known to defend their chosen style to the bitter end. Respect their opinion, what all code styles really are in the grand scheme of things, and the same respect will be returned to you. 🙂