StarMirror/CppCoreGuidelines
1
0
Fork 0
mirror of https://github.com/isocpp/CppCoreGuidelines.git synced 2024-03-22 13:30:58 +08:00
Code Issues Projects Releases Wiki Activity

Merge pull request #941 from tkruse/style-fixes

Browse Source 
Style fixes
This commit is contained in:
Gabriel Dos Reis 2017-06-02 09:17:40 -07:00 committed by GitHub
commit 4359ca5ae5
1 changed files with 87 additions and 86 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
CppCoreGuidelines.md
View File

@ -1964,13 +1964,14 @@ Having many arguments opens opportunities for confusion. Passing lots of argumen
The two most common reasons why functions have too many parameters are:
1. *Missing an abstraction.* There is an abstraction missing, so that a compound value is being
1. *Missing an abstraction.*
There is an abstraction missing, so that a compound value is being
passed as individual elements instead of as a single object that enforces an invariant.
This not only expands the parameter list, but it leads to errors because the component values
are no longer protected by an enforced invariant.
2. *Violating "one function, one responsibility."* The function is trying to do more than one
job and should probably be refactored.
2. *Violating "one function, one responsibility."*
The function is trying to do more than one job and should probably be refactored.
##### Example
@ -2389,8 +2390,8 @@ Functions with complex control structures are more likely to be long and more li
Consider:
double simpleFunc(double val, int flag1, int flag2)
// simpleFunc: takes a value and calculates the expected ASIC output,
double simple_func(double val, int flag1, int flag2)
// simple_func: takes a value and calculates the expected ASIC output,
// given the two mode flags.
{
double intermediate;
@ -2433,8 +2434,8 @@ We can refactor:
// ???
}
double simpleFunc(double val, int flag1, int flag2)
// simpleFunc: takes a value and calculates the expected ASIC output,
double simple_func(double val, int flag1, int flag2)
// simple_func: takes a value and calculates the expected ASIC output,
// given the two mode flags.
{
if (flag1 > 0)
@ -10384,17 +10385,17 @@ Readability and safety.
As an optimization, you may want to reuse a buffer as a scratch pad, but even then prefer to limit the variable's scope as much as possible and be careful not to cause bugs from data left in a recycled buffer as this is a common source of security bugs.
{
void write_to_file() {
std::string buffer; // to avoid reallocations on every loop iteration
for (auto& o : objects)
{
// First part of the work.
generateFirstString(buffer, o);
writeToFile(buffer);
generate_first_String(buffer, o);
write_to_file(buffer);
// Second part of the work.
generateSecondString(buffer, o);
writeToFile(buffer);
generate_second_string(buffer, o);
write_to_file(buffer);
// etc...
}
@ -12286,7 +12287,7 @@ This is even more true for mixed signed and unsigned arithmetic.
}
Here we have been very explicit about what's happening,
but if you had seen `us-(s+2)` or `s+=2; ... us-s`, would you reliably have suspected that the result would print as `4294967294`?
but if you had seen `us - (s + 2)` or `s += 2; ...; us - s`, would you reliably have suspected that the result would print as `4294967294`?
##### Exception
@ -15249,7 +15250,7 @@ Exception specifications make error handling brittle, impose a run-time cost, an
// ...
}
if `f()` throws an exception different from `X` and `Y` the unexpected handler is invoked, which by default terminates.
If `f()` throws an exception different from `X` and `Y` the unexpected handler is invoked, which by default terminates.
That's OK, but say that we have checked that this cannot happen and `f` is changed to throw a new exception `Z`,
we now have a crash on our hands unless we change `use()` (and re-test everything).
The snag is that `f()` may be in a library we do not control and the new exception is not anything that `use()` can do