General Coding Guidelines

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.