Airbnb’s JavaScript style guide is the most popular set of rules for code standardization available. The repository is open for contributions on GitHub. Yet, other style guides follow the same approach. They’re well maintained and available for free, such as Google‘s, Standard‘s, and Idiomatic‘s.
If you search more deeply, you can find even more style guides used by tech companies or individuals. There’s not a single way to write and format code, and that’s good and healthy.
However, even with lots of conventions documented out there, many companies prefer to write their version, which usually leads to a waste of time and effectiveness, as gathering the team to discuss aesthetic aspects of the code can be both time-consuming and exhausting.
In this article, I list reasons to enforce my opinion that choosing a community-maintained javascript style guide is the best thing for everyone — with few exceptions.
Maintaining a style guide is time-consuming
Each engineer develops a preference over time. Some people prefer tabs, others space; some prefer single quotes, others double quotes; and so on. Does the preference affect the quality of the code? I don’t think so. Does the preference affect the end-users value perception? I don’t believe it.
The fact is that quality and value aren’t expressed on coding preferences. They derive from solid processes and tools that support engineering activities. So, instead of focusing on discussing preferences, it’s more productive to focus on designing robust and well-crafted systems.
It’s fundamental to say that engineering teams and product final users benefit from a standardized codebase. The more a codebase looks like written by a single person, the faster and less buggy the development tends to be.
In this case, writing a document that states how code should look is not enough. It’s necessary to adopt and institutionalize as a practice, and the best tools available for that are linters. Linters use static code analysis to find mismatches. Examples include eslint and prettier for JavaScript, pylint for python, and rubocop for Ruby.
Community-maintained projects run this discussion with a broad reach, and detach those discussions to engineering daily activities. Maintenance is more frequent and peer-reviewed than in-house solutions.
Maintaining the linter’s configuration files is laborious
Keeping a document with the company’s rules requires dedication as new versions of the programming language or framework comes out. What engineering teams always neglect is that style guides get obsolete as people leave and join the company as well.
In small or mid-sized teams, when you hire opinionated engineers or fire senior developers, there are great chances that old discussions emerge again. As changing documentation is harder, linters’ configuration files differ from the predefined styles.
The same occurs with code documentation, which always ends up in the question: is it outdated documentation or an implementation bug?
Taking as an example the Airbnb JavaScript style guide, you can notice the documentation ships with some linters files already configured, which saves time and enforces consistency between the style guide documentation and how it performs the checks.
Faster ramp up of new-hires
If your company adopts a specific style guide with lots of custom rules for linters, then the ramp-up of new-hires is slower. The same may apply if different teams adopt different code conventions — which sounds against the idea of standardization of the code. The uniqueness of the settings increases the cognitive demand for new-hires during onboarding.
It means that adopting a community-maintained style guide helps scaling companies. In fact, I strongly recommend choosing a style guide before growing fast, as the coordination efforts of doing it afterward is significantly higher.
When you use the Airbnb, Standard, Idiomatic or whatever JavaScript style guide, the adherence to them will probably be higher than understanding and promoting your company’s own. Many of the hired engineers may already know the rules by heart, which accelerates the ramp up.
Feedback comes from the community
Prefer a community-based solution over a custom implementation. That’s what I believe is the best for companies I worked for, and what I always foster as part of SourceLevel’s culture.
Besides all the open-source benefits, the strongest point of adopting an open-source style guide is getting external feedback. Otherwise, the team relies only on their experience. The external view brings more value to the discussion.
If you the team really has strong arguments on a certain preference, the repository is open-source, and will accept a pull request or issue for discussing the matter. Of course, you can’t take the change as granted. But you definitively can collaborate with the community by sharing your opinions. And this is the kind of environment I want to promote.
Few exceptions
I think there are few exceptions to the rule. If your company is big enough, or maybe has created a framework that became very popular, then you might consider creating a public style guide. The community can help in the process, and it is a win-win.
This rule applies to big open-source projects as well. After establishing the rules for that project, it can be used by other people and companies around the world. However, if you don’t intend to put effort into maintaining it, I’d simply adopt an existing style guide.
The post Why you should adopt a community-maintained javascript style guide appeared first on SourceLevel.
Top comments (0)