[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] Style question: when should "a_" prefix be used?
From: |
Vadim Zeitlin |
Subject: |
Re: [lmi] Style question: when should "a_" prefix be used? |
Date: |
Sat, 11 Mar 2017 00:21:22 +0100 |
On Fri, 10 Mar 2017 23:15:39 +0000 Greg Chicares <address@hidden> wrote:
GC> On 2017-03-10 21:15, Vadim Zeitlin wrote:
GC> >
GC> > I'm looking at the sources trying to formulate the various style rules,
GC> > but I just can't understand what is the rule for using "a_" prefix for the
GC> > function arguments. Initially I thought that it was limited only to the
GC> > ctor arguments, but this isn't really the case, and luckily so, because if
GC> > it were, I'd have trouble finding a rationale for it, considering that
I've
GC> > just formulated a rule saying that all class members (and they only)
should
GC> > have a trailing underscore in their names, ensuring that they can't clash
GC> > with the function arguments.
GC>
GC> HA;DA, i.e., "Historical accident; don't ask".
I'm happy enough with this answer, thanks! I've condensed it down to the
last item of my current "Naming Conventions" section which looks like this
in full now:
---------------------------------- >8 --------------------------------------
Naming Conventions
------------------
### Use `snake_case_convention` for identifiers
Classes, enums, functions and variables use the same naming convention.
Notice that many existing classes use legacy `CamelCase` naming convention
instead, they should not be renamed, but new classes must not use camel case.
### Use trailing underscore for member variables
Member variables are distinguished from local variables and function parameters
by the presence of `_` at the end.
### Don't use `a_` prefix for function arguments
Although some legacy code does use this prefix, it shouldn't be used in new
code.
---------------------------------- >8 --------------------------------------
Please let me know if you have any comments (I really wish we could use a
wiki or some other of collaboratively editing this file, but I think _not_
proposing it might actually save more time in the short term, so I won't :-),
VZ