Currently at my company we have no explicit set of coding standards, and we are looking to implement and maintain some. How does this work in your team and how do you encourage engineers to adhere to the standards?
We use the Microsoft/.Net stack, but I welcome answers from engineers of all stacks.
Have a great week! 😁
Top comments (5)
I'd say there are two main ways:
Document your standards. When you're reviewing PR's/MR's, make sure people are referencing your standardisation document and ensuring things that don't adhere are flagged. The longer this document, the more chance you have it won't be reviewed 😄 .
Linting. Put as many of your standardisation rules as linting rules. For example, do your standards dictate a single quote over a double quote? Stick it in your linter! The more you can automate, the more chances you'll have of adherence!
As a bonus, you can also build in post commit hooks, CI checks etc if you really want to enforce your standards.
If there are tools and community-established guidelines for style and best practices, those are good for compliance because it can be automated. It also stings less when the program says your code needs to be updated, rather than seeming nitpicky from a person reviewing it.
For older languages without those, it is a slower process and takes initiative from someone that sees the problems and knows the general things to avoid. If there isn't an automated tool and you aren't looking to develop one, it requires everyone actively trying to internalize and follow the standards in any code they write, so adoption will be sporadic.
Either way, I think it needs to be incorporated into code review processes otherwise it isn't kept in front of everyone and becomes optional.
I work in a team of 4 developers and a CTO. We recently started weekly code reviews.
We document our findings and best practices, keep notes on what we should do and communicate the bugs that we think everyone in the team should know about.
Hi Evie, a good place to start is to examine an established company's style guide. One example is Google's JavaScript Style Guide. You can see that it is broken up into several categories. Create a document and start defining your own. You'll probably have the most difficulty with building consensus, but you have to start somewhere.
My recommendation is to start with 2-3 items. Let's say 2 related to formatting (tabs and spacing are always a good place to start) and 1 relating to app / folder structure, then go from there.
Thanks ever so much all for the helpful tips!