Merge pull request #274 from tkruse/fix-mdstyle15

consistent code formatting whitespaces around operators

CppCoreGuidelines.md

@@ -2476,12 +2476,13 @@ Using `unique_ptr` is the cheapest way to pass a pointer safely.
     {
     	auto kind = read_header(is); // read header and identify the next shape on input
     	switch (kind) {
-    	case kCicle:
+    	case kCircle:
     		return make_unique<Circle>(is);
     	case kTriangle:
     		return make_unique<Triangle>(is);
     	// ...
     	}
+    }
 
 ##### Note
 
@@ -5592,7 +5593,7 @@ Avoid resource leaks.
 
 ##### Example
 
-    unique_ptr<Foo> p {new<Foo>{7});	// OK: but repetitive
+    unique_ptr<Foo> p {new<Foo>{7}};	// OK: but repetitive
 
     auto q = make_unique<Foo>(7);		// Better: no repetition of Foo
 
@@ -5610,7 +5611,7 @@ It also gives an opportunity to eliminate a separate allocation for the referenc
 
 ##### Example
 
-    shared_ptr<Foo> p {new<Foo>{7});	// OK: but repetitive; and separate allocations for the Foo and shared_ptr's use count
+    shared_ptr<Foo> p {new<Foo>{7}};	// OK: but repetitive; and separate allocations for the Foo and shared_ptr's use count
 
     auto q = make_shared<Foo>(7);		// Better: no repetition of Foo; one object
 
@@ -6353,7 +6354,7 @@ If you don't, an exception or a return may lead to a leak.
     {
     	FILE* f = fopen(name, "r");			// open the file
     	vector<char> buf(1024);
-    	auto _ = finally([] { fclose(f); }	// remember to close the file
+    	auto _ = finally([] { fclose(f); })	// remember to close the file
     	// ...
     }
 
@@ -9812,7 +9813,8 @@ Unless you are creating a new generic library, most of the concepts you need wil
 ##### Example
 
     concept<typename T>
-    Ordered_container = Sequence<T> && Random_access<Iterator<T>> && Ordered<Value_type<T>>;	// don't define this: Sortable is in the GSL
+    // don't define this: Sortable is in the GSL
+    Ordered_container = Sequence<T> && Random_access<Iterator<T>> && Ordered<Value_type<T>>;
 
     void sort(Ordered_container& s);
 
@@ -12005,7 +12007,7 @@ Dynamic accesses into arrays are difficult for both tools and humans to validate
     // A2: Add local array_view and use that
     void f(array<int, 10> arr, int pos)
     {
-        array_view<int> a = arr, int pos)
+        array_view<int> a = {arr, pos}
         a[pos / 2] = 1; // OK
         a[pos - 1] = 2; // OK
     }
@@ -12782,9 +12784,10 @@ Member variables are always initialized in the order they are declared in the cl
     };
 
     Employee::Employee(const char* firstName, const char* lastName)
-    	: first(firstName)
+      : first(firstName),
-    	, last(lastName)
+        last(lastName),
-    	, email(first + "." + last + "@acme.com")  // BAD: first and last not yet constructed
+        // BAD: first and last not yet constructed
+        email(first + "." + last + "@acme.com")
     {}
 
 In this example, `email` will be constructed before `first` and `last` because it is declared first. That means its constructor will attempt to use `first` and `last` too soon -- not just before they are set to the desired values, but before they are constructed at all.