Many times when starting a project you will get a request for some documentation on coding standards for the project. Why? So you don’t get a bunch of coding cowboys and end up with an application that looks completely different from source file to source file.
On the other hand, if you end up with “standards” that are too strict, you may have well just built a code generator to write all the code for you because the standards will often be more verbose than most application code.
Below are ten simple standards that can replace every coding standards manual ever written.
- Don’t Repeat Yourself (DRY). If you find your code redundant and doing the same things, refactor before it’s too late.
- When making any design decision, ask yourself, what’s the easiest or simplest to explain? Pick the easiest or simplest option.
- When making any design coding decision, ask yourself, what’s more lines of code? Pick the least lines option.
- Don’t use a framework unless you really need a framework. You need a framework if it’s not more lines of code or configuration, it does not complicate the application, and it does not add redundancy to your code.
- All code should be testable because it’s not complete until it’s tested.
- Design by behavior, and don’t put two behaviors in the same class or method.
- Use simple rules for categorizing behavior: UI or Client, Business Logic, Data Centric.
- Use interfaces to define behavior, use child classes to inherit functionality, use them only if you need to share behavior or functionality, remember POJOs are your friend.
- Don’t complicate things by adding a “Go4 Pattern”, XML, external configuration, or other gold plating techniques for some nice to have minor enhancement to configurability or some other “ility”. Only use if the result is less lines of code or simpler to explain.
- Commit early and often to a repository and don’t check in untested code to the repository.