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
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.
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.