Skip to content

Latest commit

 

History

History
107 lines (60 loc) · 3.25 KB

coding-guidelines.md

File metadata and controls

107 lines (60 loc) · 3.25 KB

< devops-project-template

Coding guidelines

Coding guidelines ensure robust, maintainable code.

Clone this repo and document your coding guidelines here:



Content

Guidelines

  • Use industry standards and styles

  • Do pair programming

  • Make code self-documenting but add inline documentation (only) when needed

  • Prefer using a well-known design pattern over writing an (over-optimized) one-off solution

  • If a solution doesn't feel right, re-code (never sacrifice simplicity and elegance, never accept mediocre quality) or backlog as technical debt

  • Ensure all code, the entire project, is always in a deployable state

  • Apply design-by-contract principles

  • Apply const-correctness principles

  • Use (automated) code linting

  • Use (automated) code formatting

  • Build automated test according to the developer testing strategy

  • Code for testing-in-operation according to the acceptance testing strategy

  • Code for observability according to the optimization method and incident management procedures

Design Patterns

Design Patterns are reusable pieces of tested and documented design. Like templates.

See:

Design-by-Contract

Design-by-Contract is a concept that originated in the Eiffel language but can be used in any language. It uses assert syntax to check pre-conditions, post-conditions and invariants of a method's or function's contract. Example:

@Invariant({"title != null && title.length() > 0", "price > 0"})
public class Book {
    private final String title;
    private int price;
 
    @Requires({"title != null && title.length() > 0", "price > 0"})
    public Book(String title, int price) {
        this.title = title;
        this.price = price;
    }
 
    @Requires("price > 0")
    public void setPrice(int price) {
        this.price = price;
    } 
}

DBC is not a substitute for developer testing.

See:

Const-correctness

This is a concept that originated in early-days C++ programming but it can be applied to some degree in other languages too. It is just another form of type safety that is supported by some languages through the const-keyword..

See: