Two challenges we’ll cover here are bringing new people into the project and improving code quality. Both are not new and are relevant to any programming language, but given the nature of ReasonML, building tools to address them becomes crucial for the effectiveness of the product development.
Here’s how we approach it at Avo. In our first attempt at defining a code style the project was already a few years old and we were 4 developers.
We started out making a list of issues we face daily in the codebase. It was a collaborative document, everyone could submit there. Next, we discussed it at our developer roundtable. It's a meeting we hold every 3 weeks where all developers discuss matters related to engineering.
One of the topics on that particular roundtable was our code style. We spent an hour going through the list of suggested ideas and ended the roundtable with an actionable - one of our engineers would make a subset of the discussed topics that everyone agrees on that would become the first iteration of our official Code Style Guide. The Avo ReasonML Style Guide was born. It felt great to have a code style. On the other hand it was small and definitely incomplete, that’s why we labeled it v0.1. We had to iterate and improve, so we designed a process for that.
We use Asana to manage topics to discuss in our developer roundtable, and we have an ongoing topic for code style contenders. There anyone can suggest a new rule for the code style. Then all the contenders are discussed at the meeting and the items we agree on go into the code style. We really like this approach because it democratizes our code style and brings all new issues to the attention of all developers, so everyone knows the latest state!
Today we open our code style to the public, you can find it in this GitHub repo. Please share your ideas of new items to add to the guide in the issues section!