mirror of
https://github.com/tiennm99/styleguide.git
synced 2026-07-13 21:07:13 +00:00
Update C++ style guide to 3.174:
- Add leading blank line exception. - Improve guidance for function definition comments. - Tweak class comment example to not violate type naming guidelines. Update Objective-C style guide to 2.21: - Prohibit +new. Update JavaScript style guide to 2.9: - Add new "Function Declarations Within Blocks" section. - Add new "Internet Explorer's Conditional Comments" section. - Add new "Alias long type names to improve readability" section. - Add @lends.
This commit is contained in:
+18
-40
@@ -4,7 +4,7 @@
|
||||
|
||||
<p align="right">
|
||||
|
||||
Revision 3.171
|
||||
Revision 3.174
|
||||
</p>
|
||||
|
||||
|
||||
@@ -3151,12 +3151,12 @@ Tashana Landray
|
||||
<BODY>
|
||||
<CODE_SNIPPET>
|
||||
// Iterates over the contents of a GargantuanTable. Sample usage:
|
||||
// GargantuanTable_Iterator* iter = table->NewIterator();
|
||||
// GargantuanTableIterator* iter = table->NewIterator();
|
||||
// for (iter->Seek("foo"); !iter->done(); iter->Next()) {
|
||||
// process(iter->key(), iter->value());
|
||||
// }
|
||||
// delete iter;
|
||||
class GargantuanTable_Iterator {
|
||||
class GargantuanTableIterator {
|
||||
...
|
||||
};
|
||||
</CODE_SNIPPET>
|
||||
@@ -3260,7 +3260,7 @@ Tashana Landray
|
||||
<SUBSECTION title="Function Definitions">
|
||||
<p>
|
||||
Each function definition should have a comment describing
|
||||
what the function does and anything tricky about how it does
|
||||
what the function does if there's anything tricky about how it does
|
||||
its job. For example, in the definition comment you might
|
||||
describe any coding tricks you use, give an overview of the
|
||||
steps you go through, or explain why you chose to implement
|
||||
@@ -4356,9 +4356,10 @@ Tashana Landray
|
||||
<p>
|
||||
This is more a principle than a rule: don't use blank lines
|
||||
when you don't have to. In particular, don't put more than
|
||||
one or two blank lines between functions, don't start or end
|
||||
functions with a blank line, and be discriminating with your
|
||||
use of blank lines inside functions.
|
||||
one or two blank lines between functions, resist starting
|
||||
functions with a blank line, don't end functions with a blank
|
||||
line, and be discriminating with your use of blank lines
|
||||
inside functions.
|
||||
</p>
|
||||
<p>
|
||||
The basic principle is: The more code that fits on one screen,
|
||||
@@ -4369,39 +4370,16 @@ Tashana Landray
|
||||
whitespace.
|
||||
</p>
|
||||
<p>
|
||||
Don't start or end functions with blank lines:
|
||||
<BAD_CODE_SNIPPET>
|
||||
void Function() {
|
||||
|
||||
// Unnecessary blank lines before and after
|
||||
|
||||
}
|
||||
</BAD_CODE_SNIPPET>
|
||||
</p>
|
||||
<p>
|
||||
Don't start and end blocks with blank lines either:
|
||||
<BAD_CODE_SNIPPET>
|
||||
while (condition) {
|
||||
// Unnecessary blank line after
|
||||
|
||||
}
|
||||
if (condition) {
|
||||
|
||||
// Unnecessary blank line before
|
||||
}
|
||||
</BAD_CODE_SNIPPET>
|
||||
However, it's okay to add blank lines between a chain of
|
||||
if-else blocks:
|
||||
<CODE_SNIPPET>
|
||||
if (condition) {
|
||||
// Some lines of code too small to move to another function,
|
||||
// followed by a blank line.
|
||||
|
||||
} else {
|
||||
// Another block of code
|
||||
}
|
||||
</CODE_SNIPPET>
|
||||
Some rules of thumb to help when blank lines may be useful:
|
||||
</p>
|
||||
<ul>
|
||||
<li> Blank lines at the beginning or end of a function very
|
||||
rarely help readability.
|
||||
</li>
|
||||
<li> Blank lines inside a chain of if-else blocks may well
|
||||
help readability.
|
||||
</li>
|
||||
</ul>
|
||||
</BODY>
|
||||
</STYLEPOINT>
|
||||
</CATEGORY>
|
||||
@@ -4551,7 +4529,7 @@ Tashana Landray
|
||||
<HR/>
|
||||
|
||||
<p align="right">
|
||||
Revision 3.171
|
||||
Revision 3.174
|
||||
</p>
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user