Added items 15, 32 and 33 of C++ Coding Standards

Author: goldsborough

guidelines/item-10.md coding-standards/item-10.mdguidelines/item-10.md renamed to coding-standards/item-10.md

@@ -0,0 +1,12 @@
+# Use `const` proactively.
+
+Item 15 discusses the importance of using `const` proactively throughout your code. One of the most essential and helpful properties of `const` is that they give you one and only one point to look at when wanting to understand a variable's value. When you see `const <type> <name> = <value>`, you know immediately that throughout the lifetime of `<name>`, it will always contain `<value>` (assuming you do not use `const_cast`, which you should not unless for a very good reason). This improves maintenance greatly.
+
+Do make note of one particular quirk of C++: declaring a function parameter `const` does not affect the signature of the function. That is, the following two function signatures are equivalent:
+
+```cpp
+void f(int x);       // same
+void f(const int x); // same
+```
+
+This means that if you have a function taking an argument by value and want to make it `const` inside your function, you can make the declaration non-`const` and only `const` the argument in the definition. Be wary, however, that this does not apply to `T&` vs `const T&` (same for pointers), as in that case the difference is in the "pointee". This quirk would just mean that `T&` and `T& const` would be the same, if such a thing as a constant reference would exist (all references are constant, i.e. unmodifiable, since you cannot "repoint" them).

guidelines/item-11.md coding-standards/item-11.mdguidelines/item-11.md renamed to coding-standards/item-11.md

@@ -0,0 +1,42 @@
+# Be clear what kind of class you're writing.
+
+Just as there are design patterns for object-oriented programming, so there are patterns in the classes we usually write. Item 32 advises to know of these usual kinds of classes, and describes the following taxonomy:
+
+## Value Classes
+
+*Value classes* the most common tool in our class-toolshed. They are the basic, no-magic workhorse and identified by the following characteristics:
+
+* They have a public destructor, copy constructor and assignment operator,
+* They have no virtual functions,
+* They are intended to be used as concrete classes and not as base classes,
+* They are usually instantiated on the stack or held in another class.
+
+## Base Classes
+
+Base classes are any classes that are used as "internal nodes" in our inheritance hierarchy, i.e. any class that one or more other classes derive from. They share the following properties:
+
+* They have a virtual destructor,
+* They establish an interface through virtual functions,
+* They are usually instantiated on the heap.
+
+We could split this up into two further variants of this type of class:
+
+1. An *abstract class* is intended to be used in the context of polymorphism, i.e. pointers of their type will point to base classes,
+2. A *base class* is a class that refactors common functionality of its subclasses to avoid code duplication, but is not intended to be used for polymorphism.
+
+Note that both should be implemented in the usual ways (with virtual methods). The distinction is more in nomenclature and use.
+
+## Trait Classes
+
+A trait class is a template class that carries information about types. It is useful in the context of template metaprogramming. Such classes usually:
+
+* Contain only `typedef`s (aliases) and static functions, but do not carry state,
+* Are never instantiated (this can be enforced by `delete`ing constructors).
+
+## Exception Classes
+
+Exception classes are interesting in that they usually have both *value and reference* semantics: they are thrown by value but caught by reference. An exception class:
+
+* Has a public destructor and noexcept (copy) constructors. Otherwise you risk an abortion.
+* May have virtual functions.
+* Should derive from `std::exception` (or a subclass thereof).

guidelines/item-12.md coding-standards/item-12.mdguidelines/item-12.md renamed to coding-standards/item-12.md

@@ -0,0 +1,17 @@
+# Prefer minimal classes to monolithic classes
+
+Small classes are easier to write, read, test and implement bug-free. They are often also more reusable and much better follow the principle that each entity in your design should have one coherent, cohesive responsibility.
+
+Item 33 discusses benefits of minimal classes over monolithic ones. Those include:
+
+* A minimal class usually better embodies only a single coherent, cohesive concept, while a large class is more likely to pack in more functionality than strictly necessary.
+* A minimal class is easier to understand.
+* A minimal class that does one thing well is more easily reusable.
+* A minimal class is easier to deploy.
+* Monolithic classes are less well encapsulated. Often "fat" classes have many member functions that need not be members. Rather than giving them access to all the class' privates and breaking encapsulation, it would be better to define them as non-member functions operating on the interface of the class. In that case it is also more important to define a minimal but strong interface for the class.
+* Monolithic classes usually try to solve all possible problems. This is usually not possible, anyway.
+* Monolithic classes are often more error-prone and less easily maintainable.
+
+An example that violates this principle is `QString`, which has an insane amount of functionality to solve virtually all problems, but also has many of the shortcomings associated with monolithic classes that are discussed above. Another example is `std::string`, which duplicates a lot of functionality found in the standard's algorithms.
+
+A good example of this principle is `std::vector`, which delegates a lot of functionality, like element search, to non-member functions in the `std` namespace.