From 32f57c30cfce1681f5fe617e4fe230e88eb7b840 Mon Sep 17 00:00:00 2001 From: Tim Foley Date: Mon, 10 Dec 2018 09:13:20 -0800 Subject: Tweak coding conventions (#747) After a lot of discussion, I'm backpedaling and making this document what the (main) conventions of the codebase *are* rather than trying to prescribe what I think they should be. In particular: * Go back to `m_` for implementation-details member names, since that is the main convention in place for them * Put the `k` prefix back on C-style `enum` types since that is how they are currently being defined. My inclination is to just stick with what we have for now to avoid extended debates. Its a bit of an inconsistent mess, but its enough for getting work done. --- docs/design/coding-conventions.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) (limited to 'docs') diff --git a/docs/design/coding-conventions.md b/docs/design/coding-conventions.md index cdb9b2d91..e21538e9c 100644 --- a/docs/design/coding-conventions.md +++ b/docs/design/coding-conventions.md @@ -320,7 +320,7 @@ Of course, both of these should be avoided, so this shouldn't come up often. Constant data (in the sense of `static const`) should have a `k` prefix. -In contexts where "information hiding" is relevant/important, such as when a type has both `public` and `private` members, or just has certain operations/fields that are considered "implementation details" that most clients should not be using, and `_` prefix on function and field members is allowed (but not required). +In contexts where "information hiding" is relevant/important, such as when a type has both `public` and `private` members, or just has certain operations/fields that are considered "implementation details" that most clients should not be using, an `m_` prefix on member variables and a `_` prefix on member functions is allowed (but not required). In function parameter lists, an `in`, `out`, or `io` prefix can be added to a parameter name to indicate whether a pointer/reference/buffer is intended to be used for input, output, or both input and output. For example: @@ -342,15 +342,15 @@ C-style `enum` should use the following convention: ```c++ enum Color { - Color_Red, - Color_Green, - Color_Blue, + kColor_Red, + kColor_Green, + kColor_Blue, - ColorCount, + kColorCount, }; ``` -When using `enum class`, drop the type name as prefix, but retain the `UpperCamelCase` tag names: +When using `enum class`, drop the `k` and type name as prefix, but retain the `UpperCamelCase` tag names: ```c++ enum class Color @@ -369,13 +369,13 @@ When defining a set of flags, separate the type definition from the `enum`: typedef unsigned int Axes; enum { - Axes_None = 0, + kAxes_None = 0, - Axis_X = 1 << 0, - Axis_Y = 1 << 1, - Axis_Z = 1 << 2, + kAxis_X = 1 << 0, + kAxis_Y = 1 << 1, + kAxis_Z = 1 << 2, - Axes_All = kAxis_X | kAxis_Y | kAxis_Z, + kAxes_All = kAxis_X | kAxis_Y | kAxis_Z, }; ``` -- cgit v1.2.3