Coding guidelines are important when working in a team of software developers. These guidelines are aggregated from several projects I have participated in.
As main guidelines I identified: Explicitly over implicitly, Code poetry, Developer-oriented coding, Test-oriented coding, Re-usage of existing code.
- Explicitly over implicitly.
- We don’t use ‘fancy’ / ‘cool’ features, if there is a simpler and more explicit way to solve it.
- If you have to google an instruction, other developers probably also have to google it => make it easier and more explicit.
- Code poetry.
- Our source code should be easily readable – like a short story.
- Meaningful names for classes, functions, variables are basic conditions.
- Names should be as short as possible but as long as necessary.
- There is not a limitation of the name length.
- We apply clean code principles, e.g. a function should not contain more than 10 instructions.
- Developer-oriented coding.
- We always code for other (outside) developers, not for ourselves.
- Outside developers are our target “users” for every source code.
- We make our interfaces and usage “user-friendly”.
- Our code must do what an outside developer would expect. Examples: getDatabaseConnection() returns a DatabaseConnection- object but it does not initialize a logger.
- Test-oriented coding.
- TDD or not is up to the developer, but each pull request must contain a unit or e2e test for each critical part at the end.
- If a test cannot be easily written, the code is probably violating any of the former goals and must be refactored.
- Re-usage of existing code.
- Whenever possible we don’t code it ourselves.
- We use (open source) libraries when they are available for our requirements.