Coding styles — small remark

I have worked in several different developer teams in the last eight years. All teams had both higher educated and lower educated members. I’m quite sure that you know what I’m talking about. I’ve noticed the following phenomenon: one of the most important kick-off task should be defining the coding style every time we start a new project.

What is a coding style

Usually we have more than one alternates of writing some code snippet, especially in the script languages. I think we all have our favorites for a validator function, a controller or a DAO, or any other common parts. As an experienced engineer having best practices is a must, nothing wrong with that. But we have to form a team which means we have to adapt to each other’s habits without ruining the project. That’s why we need to define some rules BEFORE the work is started. The first rule is the coding style of the project. The coding style is nothing more than the form of our source code. In JavaScript, you can implement function, classes, blocks in different forms.

For instance: these are different (coding) styles for JavaScript functions:

Keep in mind that coding style is not just about syntactical differences, but the use of classes or code splitting or principles the team keep (DRY, DI, etc.).

Why is so important to define the coding style at the beginning of a project

Let’s assume that we just do coding on our own and let the project contains different implementation approaches like: there are some parts with IIFE-s AND OOP solutions (classes uses inheritance) AND “Promises with then”-s mixed with async/await forms AND static methods and so on. This way of working causes that the team is going to be in a terrible situation sooner or later. The problem is not that the team uses something or not, the problem is that the team uses different styles without any conventions. This makes the project unmaintainable.

My recommendation

Start your projects with a technical kick-off meeting where the team can decide, among other things, the way of working and the coding style. The outcome of the discussion should be a Code Of Conduct (CoC) paper (or whatever you call it) contains rules of the project. This paper will be incredibly useful when a newcomer arrives or someone forget some part of the ruleset. Sometimes we need to make changes in our project rules because it comes out we have better ideas. That’ normal, nothing wrong with that. Keep your CoC up to date.