fix code style

CppCoreGuidelines.md

@@ -9487,7 +9487,9 @@ For containers, there is a tradition for using `{...}` for a list of elements an
 Initialization of a variable declared using `auto` with a single value, e.g., `{v}`, had surprising results until recently:
 
     auto x1 {7};        // x1 is an int with the value 7
-    auto x2 = {7};      // x2 is an initializer_list<int> with an element 7 (this will will change to "element 7" in C++17)
+    // x2 is an initializer_list<int> with an element 7
+    // (this will will change to "element 7" in C++17)
+    auto x2 = {7};
 
     auto x11 {7, 8};    // error: two initializers
     auto x22 = {7, 8};  // x2 is an initializer_list<int> with elements 7 and 8
@@ -10856,7 +10858,7 @@ Avoid wrong results.
     unsigned int y = 7;
 
     cout << x - y << '\n';  // unsigned result, possibly 4294967286
-    cout << x + y << '\n';  // unsiged result: 4
+    cout << x + y << '\n';  // unsigned result: 4
     cout << x * y << '\n';  // unsigned result, possibly 4294967275
 
 It is harder to spot the problem in more realistic examples.
@@ -10941,10 +10943,13 @@ This makes surprises (and bugs) inevitable.
     int a[10];
     for (int i=0; i < 10; ++i) a[i]=i;
     vector<int> v(10);
-    for (int i=0; v.size()<10; ++i) v[i]=i; // compares signed to unsigned; some compilers warn
+    // compares signed to unsigned; some compilers warn
+    for (int i=0; v.size() < 10; ++i) v[i]=i;
 
     int a2[-2];         // error: negative size
-    vector<int> v2(-2); // OK, but the number of ints (4294967294) is so large that we should get an exception
+
+    // OK, but the number of ints (4294967294) is so large that we should get an exception
+    vector<int> v2(-2);
 
 ##### Enforcement
 
@@ -11200,7 +11205,10 @@ This implies added work for the programmer, is error prone, and deprives the com
 
     double data[100];
     // ... fill a ...
-    qsort(data,100,sizeof(double),compare_doubles);  // 100 chunks of memory of sizeof(double) starting at address data using the order defined by compare_doubles
+
+    // 100 chunks of memory of sizeof(double) starting at
+    // address data using the order defined by compare_doubles
+    qsort(data, 100, sizeof(double), compare_doubles);
 
 From the point of view of interface design is that `qsort` throws away useful information.
 
@@ -11215,7 +11223,9 @@ Here, we use the compiler's knowledge about the size of the array, the type of e
 
 With C++11 plus [concepts](#???), we can do better still
 
-    void sort(Sortable& c); // Sortable specifies that c must be a random-access sequence of elements comparable with <
+    // Sortable specifies that c must be a
+    // random-access sequence of elements comparable with <
+    void sort(Sortable& c);
 
     sort(c);
 
@@ -11224,7 +11234,8 @@ In this, the `sort` interfaces shown here still have a weakness:
 They implicitly rely on the element type having less-than (`<`) defined.
 To complete the interface, we need a second version that accepts a comparison criteria:
 
-    void sort(Sortable& c, Predicate<Value_type<Sortable>> p); // compare elements of c using p
+    // compare elements of c using p
+    void sort(Sortable& c, Predicate<Value_type<Sortable>> p);
 
 The standard-library specification of `sort` offers those two versions,
 but the semantics is expressed in English rather than code using concepts.
@@ -16577,7 +16588,7 @@ Of course many simple functions will naturally have just one `return` because of
 
     int index(const char* p)
     {
-        if (p==nullptr) return -1;  // error indicator: alternatively `throw nullptr_error{}`
+        if (p == nullptr) return -1;  // error indicator: alternatively "throw nullptr_error{}"
         // ... do a lookup to find the index for p
         return i;
     }