[Top][All Lists]

[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 
GC> > just formulated a rule saying that all class members (and they only) 
GC> > have a trailing underscore in their names, ensuring that they can't clash
GC> > with the function arguments.
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
---------------------------------- >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 :-),

reply via email to

[Prev in Thread] Current Thread [Next in Thread]