A programming style guide is an opinionated guide of programming conventions, style, and best practices for a team or project.
Some teams call it their coding guidelines, coding standards, or coding conventions. While these each have their own meaning in programming, they generally refer to the same thing.
For this post, I’m referring to any set of guiding programming standards used by a team in hopes of making their code more consistent as a style guide.
A team following a style guide helps everyone write code in a consistent way, and consistent code is easier to read and faster to update. Consistent code is easier to read and understand making it faster to add new features.
How can I make a programming style guide?
The first step in thinking about a programming style guide is to research the common standards for the technology you are using. Many languages have a recommended style guide, such as Golang’s official style (Effective Go).
Widely accepted style guides that you should consider to start with:
You can find more examples in this GitHub repo: A curated list of high-quality coding style conventions and standards.
Don’t reinvent the wheel. Implementing one of these generally accepted style guides is a good start to helping your team write code consistently. Beyond this starting point, your guide may change based on your team, workflow, and technology. When you make new decisions about standards and practices, add them to your style guide.
Make your style guide easy to reference. Make sure it lives somewhere accessible to everyone, such as in a company wiki. Your style guide acts as a basic code blueprint for your team during all parts of the software development lifecycle. To keep relevant, it should be often discussed. Such as during a developers onboarding, when writing code, when writing tests, and during code review.
A bit of warning, projects outside of your organization and open source projects will have their own style guides. The differences are perfectly acceptable. Again, the goal of a style guide is consistent code, not universal best practices.
