lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Style question: when should "a_" prefix be used?


From: Greg Chicares
Subject: Re: [lmi] Style question: when should "a_" prefix be used?
Date: Fri, 10 Mar 2017 23:15:39 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0

On 2017-03-10 21:15, Vadim Zeitlin wrote:
> 
>  I'm looking at the sources trying to formulate the various style rules,
> but I just can't understand what is the rule for using "a_" prefix for the
> function arguments. Initially I thought that it was limited only to the
> ctor arguments, but this isn't really the case, and luckily so, because if
> it were, I'd have trouble finding a rationale for it, considering that I've
> just formulated a rule saying that all class members (and they only) should
> have a trailing underscore in their names, ensuring that they can't clash
> with the function arguments.

HA;DA, i.e., "Historical accident; don't ask".

This occurs in just under ten percent of source files:

$ls *.?pp |wc -l
478
$grep --files-with-match '[^a-zA-Z0-9_]a_' *.?pp |wc -l    
46

...of which only three are less than ten years old:

$grep Copyright `grep --files-with-match '[^a-zA-Z0-9_]a_' *.?pp` | sort | uniq 
| grep '(C) 2' |sed -e'/2007/d' -e's/,.*//'
gpt_server.cpp:// Copyright (C) 2009
gpt_test.cpp:// Copyright (C) 2013
mec_server.cpp:// Copyright (C) 2009

...and those three are probably clones of much older originals.

I think there was a time when code like this:

  class C {
    public:  
      C(int);
    private:
      int xyz;
  };

  C::C(int xyz)
    :xyz(xyz)
  {}

couldn't be compiled, at least not with the pre-C++98 compilers
I was using then. (Now it's legal--the example above really does
compile--but it's not very nice; and if we were to use 'xyz' in
the body of the ctor, I'm not sure whether it would refer to the
argument or the member. Oh, wait...it refers to the argument,
because we can use 'this->xyz' to refer to the member. Now I'll
try to forget that again.) Anyway, rewriting the ctor with 'a_'
for "argument":
  C::C(int a_xyz)
    :xyz(a_xyz)
seemed like a good idea at the time.

And, if 'a_' was good for ctor arguments, maybe it was good for
all arguments, at least in some classes, perhaps where I wanted to
write free functions whose arguments really were data members of
some class.

Later, I started using a '_' suffix on data members, but didn't
apply that rule to old code, or at least didn't do so consistently.

>  But now I just can't formulate any rule at all. E.g. why does the recently
> added SequenceParser class ctor use "a_" for all of its arguments except
> the first one?

That class was recently renamed, but almost unchanged since 2002.
I did think of changing its 'a_'- names, but they are harmless and
don't cause any confusion unless one asks why they have that prefix,
so renaming them is one of lmi's lowest priorities--particularly
in other files, where 'a_' arguments occur in some of the hoariest
code that is most resistant to modernization, which often doesn't
even use a '_' suffix for members, so that the 'a_' still serves a
real purpose.




reply via email to

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