That’s right. All those hundreds of pages you ask your employees to read are a waste of bytes and/or paper. Sure, they flip through them and sign in the appropriate place, but we all know the vast majority gets bored after the first page and a half and skips to the end. That’s why we don’t write large documents to describe our coding standards—we write code to enforce them.
Static Code Analysis
You can tell them, but it is much better to show them. Gated check-ins (automated rejection of code that doesn’t meet the standard) make it more convenient to do the right thing. No one wants to have their code rejected (they are ready to move on to the next challenge), so developers quickly learn to write code that won’t trigger the alarm.
We have several teams, made up of multiple developers, often working on the same product at the same time. It can be hard to integrate the changes made by lots of different people in the same day if you don’t have something to help ensure the changes work well together. In addition to static code analysis, all code that is submitted has to pass all of the automated tests for that product before it is accepted. Because we are a Test-Driven Development (TDD) shop, there are lots of tests to pass before code is accepted.