https://codereview.chromium.org/1259283002/diff/40001/src/parser.h
File src/parser.h (right):
https://codereview.chromium.org/1259283002/diff/40001/src/parser.h#newcode556
src/parser.h:556: const Parameter& at(int i) const { return params[i]; }
On 2015/08/04 17:25:04, adamk wrote:
On 2015/08/04 16:46:25, caitp wrote:
> minor question: Is there a sort of system in place for deciding
whether to
name
> methods with PascalCase vs camelCase vs snake_case? All three seem
to be used
in
> V8, sometimes within the same classes (as here). The style-guide
doesn't seem
> super clear on this.
camelCase shouldn't be used in C++ (and I can't think of a place where
it is),
though we do use it in JS. For the other two, see this bit of the
Google C++
style guide:
https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Function_Names
Short answer: trivial inlined members (such as getters/setters, or
this at()
case) may have snake_case names (the idea being to signal that they
are
trivial). Any non-trivial method uses PascalCase.
What Adam said. And yes, V8 is rather inconsistent with this convention.
OTOH, I'm not even convinced the convention makes a lot of sense.
https://codereview.chromium.org/1259283002/diff/40001/src/parser.h#newcode1319
src/parser.h:1319: parser_->allow_harmony_rest_parameters() ||
is_simple);
On 2015/08/04 16:46:25, caitp wrote:
since these are just DCHECKs, why not make these more robust? Ensure
the rest
flag is used for rest, destructuring flag used for patterns. Might
avoid some
false DCHECK successes?
Good idea. Will incorporate that into the next CL.
https://codereview.chromium.org/1259283002/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
