diff --git a/cppguide.xml b/cppguide.xml index c335fc7..a3e45c2 100644 --- a/cppguide.xml +++ b/cppguide.xml @@ -4,7 +4,7 @@
-Revision 3.180 +Revision 3.188
@@ -161,7 +161,7 @@ Tashana Landray header files.
- You can significantly minimize the number of header files you
+ You can significantly reduce the number of header files you
need to include in your own header files by using forward
declarations. For example, if your header file uses the
File
class in ways that do not require access to
@@ -355,7 +355,7 @@ Tashana Landray
All of a project's header files should be
- listed as descentants of the project's source directory
+ listed as descendants of the project's source directory
without use of UNIX directory shortcuts .
(the current
directory) or ..
(the parent directory). For
example,
@@ -367,8 +367,8 @@ Tashana Landray
#include "base/logging.h"
- In dir/foo.cc
, whose main purpose is
- to implement or test the stuff in
+ In dir/foo.cc
or dir/foo_test.cc
,
+ whose main purpose is to implement or test the stuff in
dir2/foo2.h
, order your includes as
follows:
scoped_ptr
is great. You should only use std::tr1::shared_ptr
- under very specific conditions, such as when objects need to be
- held by STL containers. You should never use auto_ptr
.
+ with a non-const referent when it is truly necessary to share ownership
+ of an object (e.g. inside an STL container). You should never use
+ auto_ptr
.
- "Smart" pointers are objects that act like pointers but have
- added semantics. When a scoped_ptr
is
- destroyed, for instance, it deletes the object it's pointing
- to. shared_ptr
is the same way, but implements
- reference-counting so only the last pointer to an object
- deletes it.
-
- Generally speaking, we prefer that we design code with clear - object ownership. The clearest object ownership is obtained by - using an object directly as a field or local variable, without - using pointers at all. On the other extreme, by their very definition, - reference counted pointers are owned by nobody. The problem with - this design is that it is easy to create circular references or other - strange conditions that cause an object to never be deleted. - It is also slow to perform atomic operations every time a value is - copied or assigned. -
-- Although they are not recommended, reference counted pointers are - sometimes the simplest and most elegant way to solve a problem. - -
+auto_ptr
) can be nonobvious and confusing. The
+ exception-safety benefits of smart pointers are not decisive, since
+ we do not allow exceptions.
+ scoped_ptr
auto_ptr
shared_ptr
shared_ptr<const
+ T>
). Reference-counted pointers with non-const referents
+ can occasionally be the best design, but try to rewrite with single
+ owners where possible.
+
TODO
s should include the string TODO
in
- all caps, followed by your
+ all caps, followed by the
name, e-mail address, or other
identifier
- in parentheses. A colon is optional. The main purpose is to have
- a consistent TODO
format searchable by the person
- adding the comment (who can provide more details upon request). A
- TODO
is not a commitment to provide the fix yourself.
+ of the person who can best provide context about the problem
+ referenced by the TODO
. A colon is optional. The main
+ purpose is to have a consistent TODO
format that can be
+ searched to find the person who can provide more details upon request.
+ A TODO
is not a commitment that the person referenced
+ will fix the problem. Thus when you create a TODO
, it is
+ almost always your
+
+ name
+ that is given.
- Even when pre-processor directives are within the body of + Even when preprocessor directives are within the body of indented code, the directives should start at the beginning of the line.
@@ -4119,6 +4137,9 @@ Tashana Landray if (lopsided_score) { #if DISASTER_PENDING // Correct -- Starts at beginning of line DropEverything(); + # if NOTIFY // OK but not required -- Spaces after # + NotifyClient(); + # endif #endif BackToNormal(); } @@ -4529,7 +4550,7 @@ Tashana Landray-Revision 3.180 +Revision 3.188
diff --git a/javascriptguide.xml b/javascriptguide.xml index 325b016..61e0a24 100644 --- a/javascriptguide.xml +++ b/javascriptguide.xml @@ -3,7 +3,7 @@- Revision 2.11 + Revision 2.20
@@ -504,6 +504,15 @@ at compile time; whitespace after the slash will result in tricky errors; and while most script engines support this, it is not part of ECMAScript. +Use string concatenation instead:
+Don't do this:
-Conditional Comments hinder automated tools as they can vary the JavaScript syntax tree at runtime.
@@ -597,7 +606,6 @@variableNamesLikeThis
, ClassNamesLikeThis
,
EnumNamesLikeThis
, methodNamesLikeThis
,
and SYMBOLIC_CONSTANTS_LIKE_THIS
.
- Expand for more information.
We follow the C++ formatting rules in spirit, with the following additional clarifications.
@@ -943,19 +951,29 @@ // ... }When the function call is itself indented, you're free to start the + 4-space indent relative to the beginning of the original statement + or relative to the beginning of the current function call. + The following are all acceptable indentation styles.
+When declaring an anonymous function in the list of arguments for a function call, the body of the function is indented two spaces - from the left edge of the function call or the statement, not two - spaces from the left edge of the function keyword. This is to make - the body of the anonymous function easier to read (i.e. not be all - squished up into the right half of the screen).
+ from the left edge of the statement, or two spaces from the left + edge of the function keyword. This is to make the body of the + anonymous function easier to read (i.e. not be all squished up into + the right half of the screen).We recommend the use of the JSDoc annotations @private
and
@protected
to indicate visibility levels for classes,
functions, and properties.
The --jscomp_warning=visibility compiler flag turns on compiler + warnings for visibility violations. See + + Closure Compiler + Warnings. +
@private
global variables and functions are only
accessible to code in the same file.
Constructors marked @private
may only be instantiated by
@@ -1301,6 +1330,18 @@
new
Type{function(new:goog.ui.Menu, string)}
{?}
A description must be provided along with parameters. Use full - sentences. Method descriptions should start with a sentence written - in the third person declarative voice.
- +A description must be provided along with parameters. + When appropriate or necessary, use full sentences. Method + descriptions should start with a sentence written in the third + person declarative voice.
The compiler has limited support for template types. It can only + infer the type of this inside an anonymous function + literal from the type of the this argument and whether the + this argument is missing.
+ +Used with method, function and constructor calls to document - the arguments of a function. + the arguments of a function. + + Type names must be enclosed in curly braces. If the type + is omitted, the compiler will not type-check the parameter. | Fully supported. | @@ -2121,7 +2195,10 @@ type. When writing descriptions for boolean parameters, prefer "Whether the component is visible" to "True if the component is visible, false otherwise". If there is no return - value, do not use anFully supported. | @@ -2757,7 +2834,28 @@Yes | - +
@template | +
+ @template
+ For example: + |
+ + This annotation can be used to declare a template typename. + | +Yes with limitations. | +
@externs | @@ -3155,7 +3253,7 @@|||
+Semicolons Line length Parentheses Indentation Blank Lines Whitespace Shebang Line Comments Classes Strings TODO Comments Imports formatting Statements Access Control Naming Main |