This is an old revision of the document!
Each principle may have several alternative names. This may be because the same principle has been described several times independently from each other. A principle may also evolve over time, change its name, change its meaning, may be applied to other contexts, etc. So there may be several names referring basically to the same principle. This also means that the alternative names may roughly correspond to certain views on the principle. The views may differ slightly resulting in certain variations of the principle.
Alternative names are listed in this section and, if necessary, explained. Variations are also explained and, depending on the difference, may additionally be described on a separate wiki page.
Principles apply in certain contexts. A context is a basic category for principles like OOD, web development, framework development, user interface design, etc. Is describes during which task the principle can be considered. A principle has at least one context but also may have several contexts.
The definition section states the principle is one or two sentences. This may be the original wording or a new one.
As one or two sentences is never enough to explain a principle in detail, there is a separate section describing what the principle means and how it is applied.
Principles normally are not hard rules but rather heuristics or rules of thumb. So there is no formal proof showing that the principle is correct in each and every situation. Nevertheless there needs to be a reason for the principle, meaning some rationale explaining why it holds. In order to apply the principle, the rationale is applied to the given design problem that is to be solved. If the rationale holds in this case, the principle may be applied.
This section describes where the principle comes from, where it has been prominently described, etc.
Apart from the rationale there may be different evidence that the principle holds:
There are certain relationships among principles. This section lists and explains them so the consideration of one principle inevitably leads to other principles that can be considered.
A generalization of the principle is another principle that can be applied in a broader context or one that is less demanding. The principle is always a specialization of its generalizations. A principle may have several generalizations, for example when it is a consequence of two other principles.
A specialization is a more concrete principle that either applies in a narrower context, or makes more prescriptions, or is some kind of corollary. The principle is always a generalization of its specializations.
Following the principle may have a negative impact on aspects addressed by other principles. These contrary principles are listed here and the consequence is explained. As with the principle itself the negative effect concerning the other principles are not guaranteed. There is just a high probability that there is this effect. Therefore these principles should also be considered if this one is applied. Typically but not necessarily a principle is contrary to its contrary principles.
A principle is always a reduction of the given design problem to a very specific aspect or effect. Other principles have to be considered too in order to have a full picture of the design problem. Sometimes when one principle is considered, another one is very likely to be relevant, too. Then this is a complementary principle.
A self-contained example explains how the principle distinguished “good” and “bad” solutions with respect to the aspect the principle is about.
As the wiki page evolves, it gets better and better. This section roughly states how complete it already is:
Apart from the original source which may be already mentioned inthe origin section there may be other articles, discussions and wikis discussing the principle. If they are worth looking into, they are listed here.