Introducing Coding Standards for Higher Efficiency
Preface
I was busy coding on a sunny morning at the Karachi office, when I heard my colleague sigh and hold his head in frustration. He had been working on a feature in isolation for a few days and finally synced his code with the develop branch only to face a ton of merge conflicts. This was not because there was any major change in functionality of any of the files, but they were simply committed with different indentation settings.
We realized we needed to implement a strict set of coding standards to improve the efficiency of the development team.
The Status Quo
Although our backend codebase had TSLint already set up:
- The TSLint configuration file was changed frequently to accommodate for the different coding styles of developers. This defeated the purpose of TSLint altogether since everyone was coding in their own style, and there was no standardization.
- TSLint rules were not enforced and a developer could simply choose to ignore the warnings.
Choosing the Right Tools
After some research and consultation with the Architects Group, we decided to go with the following tools:
We adopted ESLint because TSLint has been deprecated with the recommendation that people migrate over to ESLint. For rules, we decided to go with Typescript-ESLint Recommended rules with a few minor changes.
We also added a tool called Prettier and an accompanying utility pretty-quick, as these are specialized packages to automate formatting. Although Prettier has a limited set of rule options, it fulfills our requirement for maintaining a consistent code style.
This prevents us from running into conflicts due to different indentations and coding styles. I would recommend reading why to use Prettier and how it’s different from Linters for a better understanding of the advantages of using this tool. Popular editors such as VS Code can be configured to format code on every change.
Enforcement
Choosing tools was the simpler task, as the challenge lay in ensuring the usage of these tools. Our plan to enforce the new process was broken into two parts:
- Format all existing codebase according the the new rules of ESLint and Prettier
- Add pre-commit hooks so that any new code also follows the same rules
For the first part, we had to plan it in a way that no other developer on the team was affected by it. We communicated this plan over to the entire team in advance and asked them to check their pending code. On the planned day, we formatted the entire codebase according to the new format.
Secondly, we added the pre-commit hooks straight away so that moving forward, anyone who writes any new code adheres to the new coding standards.
This ensures that any new code is auto-formatted before commit. If any code cannot be auto-formatted, the commit will fail and the developer will be required to fix the issues manually.
The “Why” Behind This
It’s important to understand what impact these changes have on the efficiency of the overall team. Since the entire codebase is formatted and written in a consistent manner, it is easier for everyone to:
- Read and understand it
- Maintain it
- Reuse and extend it
These benefits will continue to increase as team size increases.
Conclusion
It does not matter what standards you follow, but it is important to follow one specific standard or format to improve the efficiency of the entire team. This may be a small change but the benefits of it will be felt by your team members in the long run.
Hussain works on the Technology Team as a Full-Stack Software Engineer. He loves to read, explore new technologies and has recently taken up writing as a hobby. He can be reached at hussain.ali@rideairlift.com. To join our team, please click here to visit our job board to browse open positions.
