This flexibility can lead to endless discussions of “what’s best” or “what’s most efficient” and worse can lead to project code that can resemble a big steamy bowl of pasta with brownish marinara. As a team leader, the last thing you want is to have to code walk dozens of coding styles. As a coder and team member the last thing you what to do is traverse hundreds of lines of code that has bad indentation or horrible style.
So, as a manager, you need to adopt a strict coding standard and ruthlessly enforce it.
Coding Standard Objectives
Here is a short bullet list. The standards should…
- match the team’s current experience and talent,
- should closely follow at least one major published standard,
- should have justifications for each decision, and include team consensus.
For the Java Team
So lets begin with the java programming team–what standards would suite them best? The choice is easy–use a classical implementation with factory generated components that implement IoC through parameter injection. Think of it this way, every file is a class defined by a named function variable (the function is still technically anonymous). Its injection is always through construction (think ruby opts), and always factory built. Files are organized as pseudo-package folders that may (or may not) have package namespaces.
For good published standards, start here:
Our Standards Document
My best advise is to find a good published standard, modify it for your team’s abilities, then stick with it. You will need to add rules as time goes on–because coders will always find differing ways to interpret the rules. So be prepared for additions–not so much changes, just clarifications.