We also use foo() and set_foo() for simple getters/setters (with const-correctness whenever possible.)

Suggestion: s/errors/JavaScript errors/ - this section could be interpreted to mean that throw is allowed.

IMHO Google's style guide is still a good reference.

...the C++ linter (based on [Google's `cpplint`](https://github.com/google/styleguide), and which can...

When I grew up this was called PascalCase, and camel case is what's now known as lowerCamelCase

I’ve never heard of that term, and in any case the example’s very purpose is to avoid any ambiguity about what is meant.

👍 Cool. Examples beat all.

Please escape the underscores for non-GitHub markdown readers.

thanks, done!

This sentence sounds odd being positioned here, sandwiched between two sentences talking about JavaScript errors.

I’ve moved it to the end. I added it because it seemed to make sense to me that, like @bnoordhuis said, there might be confusion about what “throwing” means, but I’d also be happy just dropping it

Should this perhaps be make lint-cpp instead? Running make cppilnt target produces the following warning:

$ make cpplint
Running C++ linter...
Total errors found: 0
Please use lint-cpp instead of cpplint

@danbev yes, I guess so :)

Could these two be clarified... slightly?

Do you have any specific question? I realize this isn’t helpful when it comes to which-do-I-use, but then again we don’t really follow any specific rules for this right now. (I assume @bnoordhuis is a fan of just aborting in OOM situations, me not so much. 😄)

Oh, ok. On re-reading it I think I understand, maybe we could clarify the wording like so:

- Use `Malloc()`, `Calloc()`, etc. from `util.h` to cause an abort in Out-of-Memory situations.
- Use `UncheckedMalloc()`, etc. to return a `nullptr` in OOM situations.

another common pattern is how we handle indentation of initialization lists. example:

HandleWrap::HandleWrap(Environment* env,
                       Local<Object> object,
                       uv_handle_t* handle,
                       AsyncWrap::ProviderType provider)
    : AsyncWrap(env, object, provider),
      state_(kInitialized),
      handle_(handle) {

basically: if the initialization list does not fit on one line then it returns to the next line, indents 4 spaces then starts with the colon. Every additional member in the list starts on a new line and indented 6 spaced, to align with the first member in the list.

it may be worth mentioning usage of const_cast (since it's used in core) but not sure if there's a solid rule of when it's acceptable.

const_cast: should be used sparingly and only when it's still conceptually const afterwards.

there is nothing specific to Node about using const_cast, anything we’d write down here would apply to any other C++ code as well

the linter doesn't currently catch whether the operation is at the end of the line or the beginning of the next line. couple examples:

// ternary
int r = true ?
    1 : 0;
int r = true
    ? 1 : 0;

// conditional
if (foo &&
    bar) { }
if (foo
    && bar) { }

specify this?

@addaleax /cc @bnoordhuis

The && should go on the same line as the expression preceding it. (edit: but I believe the linter already complains about that.)

Ternary operator: we don't have a hard rule, I think, but IMO if it doesn't fit on a single line, you should be using an if statement anyway.

re: placement of &&. linter doesn't check that. should be possible to add to the linter? if so then no reason to put it here.

The parens can probably be dropped here.

Parens could be dropped here as well.

This is capitalized in CONTRIBUTING.md, I'd suggest to do the same here.

done!

No doubt this is correct, but it always bothers me with multiple variables:

void* foo, * bar;

I'd just declare one variable per line

Also for loops (unless conditionals includes loops).

while (something)
  ChangeSomething();

Now that I am thinking about it, I am not sure we use loops without parens...

Yeah, conditionals includes conditional loops. :) Anyway, I don’t think the current phrasing leaves anybody thinking that we use indentation other than 2 spaces.