Do you have code standards for your software development teams? Most companies don’t. They go to great lengths to produce all kinds of document templates yet coders are allowed to do whatever they please. Odd.
The reason document templates are widely used is simply to promote standardization. For example, when you pick up a project vision statement written by someone in Company X you know what to expect. There are standard sections and a common approach to laying out the project goals, costs, etc.
If a standard template didn’t exist, those vision statements would be all over the lot. You’d might have trouble finding the information you want. Even worse, comparing two or more projects would be much more difficult.
Of course, we can’t produce a common set of templates for all the code a development team will write. It’s just not practical. Yet, there are simple guidelines that can make code more readable and less costly to support.
Start out slowly. Keep the guidelines minimalist. You want consistency in the code. Seek consensus on the team and don’t be too picky. I’ve seen teams argue about tabs versus spaces. Those details are not important. The code must be maintainable by anyone on the team. That is the number one goal.
When establishing guidelines, here are some things to consider:
- File naming, layouts and directory structures
- Build conventions and make files
- Declarations and initializations
- Variable naming conventions
- Internal error handling and assert usage
- Error reporting and logging
- Event processing, logging and audit trails
- UI conventions
- Language-specific guidelines
You don’t need to cover all these areas. Decide what’s important to your team (and your business). Obtain consensus and put a process in place to spot check compliance. In the long run, everyone will be better off.