Merge pull request #212 from tkruse/fix-mdstyle12

Fix code snippets that do not compile, or mark them with ???
This commit is contained in:
Gabriel Dos Reis 2015-09-29 09:03:38 -07:00
commit 1ad595e1a6

View File

@ -7157,16 +7157,16 @@ Some of these expressions are unconditionally bad (e.g., they rely on undefined
**Example**: **Example**:
x=k*y+z; // OK x=k*y+z; // OK
auto t1 = k*y; // bad: unnecessarily verbose auto t1 = k*y; // bad: unnecessarily verbose
x = t1+z; x = t1+z;
if(0<=x && x<max) // OK if(0<=x && x<max) // OK
auto t1 = 0<=x; // bad: unnecessarily verbose auto t1 = 0<=x; // bad: unnecessarily verbose
auto t2 = x<max; auto t2 = x<max;
if(t1 && t2) // ... if(t1 && t2) // ...
**Enforcement**: Tricky. How complicated must an expression be to be considered complicated? Writing computations as statements with one operation each is also confusing. Things to consider: **Enforcement**: Tricky. How complicated must an expression be to be considered complicated? Writing computations as statements with one operation each is also confusing. Things to consider:
@ -7475,8 +7475,8 @@ There can be code in the `...` part that causes the `delete` never to happen.
{ {
int a1[7]; int a1[7];
int a2[9]; int a2[9];
if (&a1[5]<&a2[7]) // bad: undefined if (&a1[5] < &a2[7]) {} // bad: undefined
if (0<&a1[5]-&a2[7]) // bad: undefined if (0 < &a1[5] - &a2[7]) {} // bad: undefined
} }
**Note**: This example has many more problems. **Note**: This example has many more problems.
@ -10775,7 +10775,7 @@ Dynamic accesses into arrays are difficult for both tools and humans to validate
**Example; good**: **Example; good**:
// ALTERNATIVE A: Use an array_view // ALTERNATIVE A: Use an array_view
void f() void f1()
{ {
int arr[COUNT]; int arr[COUNT];
array_view<int> av = arr; array_view<int> av = arr;
@ -10784,7 +10784,7 @@ Dynamic accesses into arrays are difficult for both tools and humans to validate
} }
// ALTERNATIVE B: Use at() for access // ALTERNATIVE B: Use at() for access
void f() void f2()
{ {
int arr[COUNT]; int arr[COUNT];
for (int i = 0; i < COUNT; ++i) for (int i = 0; i < COUNT; ++i)
@ -11152,25 +11152,25 @@ Choose a "house style", but leave "imported" libraries with their original style
**Example**, ISO Standard, use lower case only and digits, separate words with underscores: **Example**, ISO Standard, use lower case only and digits, separate words with underscores:
int * `int`
vector * `vector`
my_map * `my_map`
Avoid double underscores `__` Avoid double underscores `__`
**Example**: [Stroustrup](http://www.stroustrup.com/Programming/PPP-style.pdf): **Example**: [Stroustrup](http://www.stroustrup.com/Programming/PPP-style.pdf):
ISO Standard, but with upper case used for your own types and concepts: ISO Standard, but with upper case used for your own types and concepts:
int * `int`
vector * `vector`
My_map * `My_map`
**Example**: CamelCase: capitalize each word in a multi-word identifier **Example**: CamelCase: capitalize each word in a multi-word identifier
int * `int`
vector * `vector`
MyMap * `MyMap`
myMap * `myMap`
Some conventions capitalize the first letter, some don't. Some conventions capitalize the first letter, some don't.
@ -11961,11 +11961,11 @@ The `string`s of `v` are destroyed upon exit from `bad()` and so is `v` itself.
**Example**: **Example**:
vector ??? vector
**Example**: **Example**:
factory ??? factory
**Enforcement**: Check for pointers and references returned from functions and see if they are assigned to resource handles (e.g., to a `unique_ptr`). **Enforcement**: Check for pointers and references returned from functions and see if they are assigned to resource handles (e.g., to a `unique_ptr`).