Commit 5b130489 by Jamie Madill

Audit and amend style guide.

BUG=None Change-Id: Idb6863c93f639dfe4770e67710159f3e398c5238 Reviewed-on: https://chromium-review.googlesource.com/360890Reviewed-by: 's avatarGeoff Lang <geofflang@chromium.org> Reviewed-by: 's avatarOlli Etuaho <oetuaho@nvidia.com> Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>
parent 90892fbd
...@@ -10,6 +10,9 @@ below. ...@@ -10,6 +10,9 @@ below.
Items marked {DEV} indicate a deviation from the Google guidelines. Items marked Items marked {DEV} indicate a deviation from the Google guidelines. Items marked
{DO} are reiterating points from the Google guidelines. {DO} are reiterating points from the Google guidelines.
Before you upload code to Gerrit, use `git cl format` to auto-format your code.
This will catch most of the trivial formatting errors and save you time.
### [Header Files](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Header_Files) ### [Header Files](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Header_Files)
* We will use **`.h`** for C++ headers. * We will use **`.h`** for C++ headers.
...@@ -23,27 +26,21 @@ Items marked {DEV} indicate a deviation from the Google guidelines. Items marked ...@@ -23,27 +26,21 @@ Items marked {DEV} indicate a deviation from the Google guidelines. Items marked
### [Classes](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Classes) ### [Classes](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Classes)
* {DO} disable Copy and Assignment constructors using the * {DEV} Inherit (privately) from angle::NonCopyable helper class (defined in
DISALLOW\_COPY\_AND\_ASSIGN macro (defined in common/angleutils.h) in the common/angleutils.h) to disable default copy and assignment operators.
**private** section of a class: ``` class Foo { public: Foo(int f); ~Foo();
private: DISALLOW_COPY_AND_ASSIGN(Foo); }; ```
### [Other C++ Features](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Other_C++_Features) ### [Other C++ Features](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Other_C++_Features)
* {DEV} all parameters passed by reference, except for STL containers (e.g. * {DEV} all parameters passed by reference, except for STL containers (e.g.
std::vector, std::list), must be labeled `const`. For return parameters std::vector, std::list), must be labeled `const`. For return parameters
other than STL containers, use a pointer. other than STL containers, use a pointer.
* {DO} avoid use of default arguments. exception: for functions emulating * {DO} avoid use of default arguments.
variadic arguments, they are allowed.
* {DONT} use C++ exceptions, they are disabled in the builds and not caught. * {DONT} use C++ exceptions, they are disabled in the builds and not caught.
* {DO} use nullptr (instead of 0 or NULL) for pointers. * {DO} use nullptr (instead of 0 or NULL) for pointers.
* {DO} use size\_t for loop iterators and size values. * {DO} use size\_t for loop iterators and size values.
* {DO} use uint8\_t pointers instead of void pointers to denote binary data. * {DO} use uint8\_t pointers instead of void pointers to denote binary data.
* {DO} use C++11 according to the [Chromium guide on C++11] * {DO} use C++11 according to the [Chromium guide on C++11]
(http://chromium-cpp.appspot.com/). (http://chromium-cpp.appspot.com/).
* {DEV} we permit C++11 STL classes inside the D3D Renderers, since D3D is
only supported on MSVS.
### [Naming ](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Naming) ### [Naming ](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Naming)
...@@ -53,14 +50,16 @@ Items marked {DEV} indicate a deviation from the Google guidelines. Items marked ...@@ -53,14 +50,16 @@ Items marked {DEV} indicate a deviation from the Google guidelines. Items marked
If the file is an implementation of a class, the filename may be capitalized If the file is an implementation of a class, the filename may be capitalized
the same as the major class. the same as the major class.
* {DEV} We use .cpp (instead of .cc), .h and .inl (inlined files) for C++ * {DEV} We use .cpp (instead of .cc), .h and .inl (inlined files) for C++
files and headers. #### Directory Names files and headers.
#### Directory Names
* Directory names should be all lowercase, unless following an externally * Directory names should be all lowercase, unless following an externally
imposed capitalization (eg include/EGL, or src/libGLESv2, etc) imposed capitalization (eg include/EGL, or src/libGLESv2, etc)
#### Variable Names #### Variable Names
Use the following guidelines, they do deviate somewhat from the Google Use the following guidelines, they do deviate somewhat from the Google
guidelines. guidelines.
* class and type names: start with capital letter and use CamelCase. * class and type names: start with capital letter and use CamelCase.
* {DEV} class member variables: use an **`m`** prefix instead of trailing * {DEV} class member variables: use an **`m`** prefix instead of trailing
...@@ -71,7 +70,7 @@ underscore and use CamelCase. ...@@ -71,7 +70,7 @@ underscore and use CamelCase.
use CamelCase (chosen for consistency) use CamelCase (chosen for consistency)
* Constants: start with a **`k`** and use CamelCase * Constants: start with a **`k`** and use CamelCase
* namespaces: use all lower case * namespaces: use all lower case
* Enumerator Names - follow constants * Enum Names - use class enums, and the values should be uppercase with underscores.
* macros: all uppercase with underscores * macros: all uppercase with underscores
* exceptions to naming: use common sense! * exceptions to naming: use common sense!
...@@ -82,7 +81,7 @@ use CamelCase (chosen for consistency) ...@@ -82,7 +81,7 @@ use CamelCase (chosen for consistency)
``` ```
// //
// Copyright (c) 2002-2011 The ANGLE Project Authors. All rights reserved. // Copyright (c) 2016 The ANGLE Project Authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be // Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file. // found in the LICENSE file.
// //
...@@ -90,16 +89,14 @@ use CamelCase (chosen for consistency) ...@@ -90,16 +89,14 @@ use CamelCase (chosen for consistency)
### [Formatting](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Formatting) ### [Formatting](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Formatting)
* {DEV} Avoid excessively long lines. Please keep lines under 120 columns * {DEV} Avoid excessively long lines. Please keep lines under 100 columns
long. long.
* Use unix-style newlines. * Use unix-style newlines.
* {DO} use only spaces. No tab characters. Configure your editor to emit * {DO} use only spaces. No tab characters. Configure your editor to emit
spaces when you hit the TAB-key. spaces when you hit the TAB-key.
* {DEV} indent 4 spaces at a time. * {DEV} indent 4 spaces at a time.
* conditionals: place space outside the parenthesis. No spaces inside. * conditionals: place space outside the parenthesis. No spaces inside.
* switch statements: indent the case statements by 2 spaces. The body of the * switch statements: use the output of `git cl format`.
case statements should be intended another 2 spaces so that they are a full
4-space indent from the switch.
* class format(eg private, public, protected): indent by 2 spaces. Regular * class format(eg private, public, protected): indent by 2 spaces. Regular
4-space indent from the outer scope for declarations/definitions. 4-space indent from the outer scope for declarations/definitions.
* pointers and references: **`*`** and **`&`** tight against the variable * pointers and references: **`*`** and **`&`** tight against the variable
...@@ -156,8 +153,3 @@ const string &str; ...@@ -156,8 +153,3 @@ const string &str;
* If modifying pre-existing code that does not match the standard, the altered * If modifying pre-existing code that does not match the standard, the altered
portions of the code should be changed to match the standard. portions of the code should be changed to match the standard.
* For changes which fix bugs, we do not require that pre-existing style issues
be addressed in the change itself, but reviewers may request a follow-on CL
to address style inconsistencies. This exception does not apply to changes
which implement new features, perform refactoring, or introduce a style
issue or inconsistency themselves.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment