The title has spitted what I am going to talk about in this short article out. As a software developer since in college, I have faced these kinds of argument between team members about what the programming style (coding convention) is for everyone to follow a lot. Although whether a programming style is fit or not seems like a subjective question, I still believe that there is a baseline which should be acceptable for everyone, which is exactly what the title says.

Let us take C# for example. The .NET Standard is a set of fundamental APIs for all runtimes and serves as standard library in .NET world. Obviously, you can see a clear, unified programming style from it without reading the official C# Coding Convention: each interface’s name starts with I, name of types, namespaces and public members follows Upper Camel Case, static fields are usually read-only….and more. When you and your peers are planning a programming style for your team, you shall not defy or contradict the style that the .NET Standard has.

If you illustrate the relation between the programming styles of yours and standard library, they can be depicted in following figures. In Example 1, your rule set of style is extended from standard library’s style. In Example 2, on the other hand, a part of standard library’s style is not followed (the black area).

The reasons of why former is better than latter are:

Programming without fundamental APIs is almost impossible. If you have a programming style that does not match it, you will see two or more styles for same programming language in your source code. Your teammates came from similar background (in this example, .NET developers) or you would not be in same development team. Because of that, the fundamental APIs should be the common ground you have. A programming style based on it should be more acceptable than the one from scratch.

The reasoning above goes well for other mainstream programming languages such as Java, Python, JavaScript and PHP. Each language has its standard library or fundamental APIs respectively. Before you establishing the convention for your team, take a five minutes to see what the style it has, or read the official guideline like C# and Java. And I believe things will go smoother.