diff --git a/cppguide.xml b/cppguide.xml index 433d614..5e351ae 100644 --- a/cppguide.xml +++ b/cppguide.xml @@ -2464,9 +2464,23 @@ Tashana Landray Compressed Pair from boost/compressed_pair.hpp
  • - Pointer Container from boost/ptr_container except - ptr_array.hpp and serialization + Pointer Container from boost/ptr_container except serialization
    • +
  • + Array from boost/array.hpp +
    • +
  • + The Boost Graph Library (BGL) from boost/graph except serialization +
    • +
  • + Property Map from boost/property_map.hpp +
    • +
  • The part of + + Iterator that deals with defining iterators: + boost/iterator/iterator_adaptor.hpp, + boost/iterator/iterator_facade.hpp, and + boost/function_output_iterator.hpp
    • We are actively considering adding other Boost features to the list, so this rule may be relaxed in the future. @@ -3167,11 +3181,13 @@ Tashana Landray often be more readable to line them up:

    - ... DoSomething(); // Comment here so the comments line up. DoSomethingElseThatIsLonger(); // Comment here so there are two spaces between // the code and the comment. - ... + { // One space before comment when opening a new scope is allowed, + // thus the comment lines up with the following comments and code. + DoSomethingElse(); // Two spaces before line comments normally. + } @@ -3783,10 +3799,9 @@ Tashana Landray const string & str; // Bad - spaces on both sides of &

    - You should do this consistently within a single file or - - - so when modifying an existing file, use the style in that + You should do this consistently within a single + file, + so, when modifying an existing file, use the style in that file.

    diff --git a/objcguide.xml b/objcguide.xml index aebeb55..7b3ee69 100644 --- a/objcguide.xml +++ b/objcguide.xml @@ -49,13 +49,13 @@ Google's general recommendations. So, before reading this guide, please make sure you've read: @@ -80,10 +80,10 @@

    Google has already released open-source code that conforms to these - guidelines as part of the Google Toolbox for - Mac project (abbreviated GTM throughout this document). Code meant to - be shared across different projects is a good candidate to be included in - this repository. + guidelines as part of the Google + Toolbox for Mac project (abbreviated GTM throughout this document). + Code meant to be shared across different projects is a good candidate to + be included in this repository.

    @@ -91,8 +91,8 @@

    Note that this guide is not an Objective-C tutorial. We assume that the reader is familiar with the language. If you are new to Objective-C or - need a refresher, please read - The Objective-C Programming Language. + need a refresher, please read The + Objective-C Programming Language.

    @@ -341,8 +341,8 @@ Naming rules are very important in maintainable code. Objective-C method names tend to be very long, but this has the benefit that a block of code can almost read like prose, thus rendering many comments unnecessary.

    -

    When writing pure Objective-C code, we mostly follow standard - Objective-C naming rules. These naming guidelines may differ +

    When writing pure Objective-C code, we mostly follow standard Objective-C + naming rules. These naming guidelines may differ significantly from those outlined in the C++ style guide. For example, Google's C++ style guide recommends the use of underscores between words in variable names, whereas this guide recommends the use of intercaps, @@ -1070,8 +1070,8 @@ handled by the Objective-C runtime. If the method has no return result, you're good to go. However if there is one, there may be differences based on runtime architecture, return size, and OS X - version (see - Apple's documentation for specifics). + version (see Apple's + documentation for specifics).

    Note that this is very different from checking C/C++ pointers against