Coding guidelines ensure robust, maintainable code.
Clone this repo and document your coding guidelines here:
Content
-
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 are reusable pieces of tested and documented design. Like templates.
See:
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:
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: