How do you normalize coding style among multiple isolated developers

In this tutorial, We will shared how do you normalize coding style among multiple isolated developers:

  1. Have a coding standard. If the shop you’re going to work for already has one in use, that’s the one you follow. Avoid coding standards that are dozens of pages long; it’s not that complicated. Instead, look at code you like on Github, and follow that style. Find the well-established idioms for your particular programming language (camelCase, etc.), and use them.
  2. Let the IDE and code style tools do most of the work for you. For example, Visual Studio already has most of the important rules in place. Don’t like how a piece of code is formatted? Ask Visual Studio to reformat it for you. Problem solved.
  3. Hire software developers that know what they are doing. They’ll write good code without having to slavishly follow a style guide.
  4. Have code reviews. Seek consensus based on function and readability. Don’t like the consensus? One person is the tie-breaker; their decision stands.
  5. Don’t strive for perfection; you’ll never get it (for many, many reasons that are outside the scope of this question). Instead, strive for improvement.
  6. Try not to waste a lot of time and money on things that don’t matter. In particular, don’t rewrite code that already works and is already well-tested, just to satisfy your own sensibilities about what that code should look like.
  7. Learn how to write functions and methods that do one thing and do it well. If you do that, your naming should take care of itself (the name is a short verb phrase that describes what the function does).
  8. If you’re doing OO, learn how to write small classes that have one responsibility/point of modification. If you do that, your naming should take care of itself (the name is a short noun phrase that describes what the class is).
  9. Learn how to write code that is easily testable. If you do that, the unit tests will take care of themselves.
  10. Pick your battles. Does that small, obscure proclivity that one of the developers exhibits really matter? Avoid religions and dogma.
  11. Finally, remember that the code is not yours. Don’t be sentimental about it. You should “own” it and make changes as required (so, in that sense, it is yours), but it’s there to serve a purpose. Being overly attached to the code only gets in the way of that by preventing objective analysis of the pros and cons of large-scale changes or decisions about the structure of the code and making you object to compromise.


If you like FreeWebMentor and you would like to contribute, you can write an article and mail your article to [email protected] Your article will appear on the FreeWebMentor main page and help other developers.

Recommended Posts:

Editorial Staff

Editorial Staff at FreeWebMentor is a team of professional developers.