Connecting Tech Pros Worldwide Forums | Help | Site Map

Accessors/modifiers naming convention

Ook
Guest
 
Posts: n/a
#1: Oct 11 '05
Is there any kind of naming convention for accessor and modifiers? What I've
been doing is something like this:

// accessor
int getSize();

// Modifier
void setSize( int newsize);

private:
int _size;



Kristo
Guest
 
Posts: n/a
#2: Oct 11 '05

re: Accessors/modifiers naming convention


Ook wrote:[color=blue]
> Is there any kind of naming convention for accessor and modifiers? What I've
> been doing is something like this:[/color]

Naming conventions are a coding standards concept, which is something
not covered by the C++ standard. I believe the FAQ has links to a few
good ones that you could take a look at.
[color=blue]
> // accessor
> int getSize();
>
> // Modifier
> void setSize( int newsize);[/color]

Sure, a lot of people name accessor/modifier functions this way.
[color=blue]
> private:
> int _size;[/color]

Now *that* isn't allowed. Leading underscores are reserved for the
implementation. I suggest changing that to size_.

Kristo

Ook
Guest
 
Posts: n/a
#3: Oct 11 '05

re: Accessors/modifiers naming convention


>> private:[color=blue][color=green]
>> int _size;[/color]
>
> Now *that* isn't allowed. Leading underscores are reserved for the
> implementation. I suggest changing that to size_.
>
> Kristo[/color]

Seriously? I've always been taught that you should use leading underscores
for your private variables.


red floyd
Guest
 
Posts: n/a
#4: Oct 11 '05

re: Accessors/modifiers naming convention


Ook wrote:[color=blue][color=green][color=darkred]
>>>private:
>>> int _size;[/color]
>>
>>Now *that* isn't allowed. Leading underscores are reserved for the
>>implementation. I suggest changing that to size_.
>>
>>Kristo[/color]
>
>
> Seriously? I've always been taught that you should use leading underscores
> for your private variables.
>
>[/color]

Technically no. Per 17.4.3.1.2/1, identifiers with a leading underscore
and a *LOWER CASE* letter are only reserved in the global and std
namespaces.

Per 17.4.3.1.2/1, identifiers witha leading underscore followed by an
UPPER CASE letter are reserved, period.

In either case, you're better off not using leading underscores at all.
Kristo
Guest
 
Posts: n/a
#5: Oct 11 '05

re: Accessors/modifiers naming convention


Ook wrote:[color=blue][color=green][color=darkred]
> >> private:
> >> int _size;[/color]
> >
> > Now *that* isn't allowed. Leading underscores are reserved for the
> > implementation. I suggest changing that to size_.
> >
> > Kristo[/color]
>
> Seriously? I've always been taught that you should use leading underscores
> for your private variables.[/color]

You've been taught wrong. ;-) *Trailing* underscores, however, are a
common practice to indicate private member variables.

Kristo

P.S. Please attribute your quotes when posting a follow-up.

Greg Comeau
Guest
 
Posts: n/a
#6: Oct 11 '05

re: Accessors/modifiers naming convention


In article <1129044046.615375.248530@g47g2000cwa.googlegroups .com>,
Kristo <kristo605@gmail.com> wrote:[color=blue]
>Ook wrote:[color=green]
>> Is there any kind of naming convention for accessor and modifiers? What I've
>> been doing is something like this:[/color]
>
>Naming conventions are a coding standards concept, which is something
>not covered by the C++ standard. I believe the FAQ has links to a few
>good ones that you could take a look at.
>[color=green]
>> // accessor
>> int getSize();
>>
>> // Modifier
>> void setSize( int newsize);[/color]
>
>Sure, a lot of people name accessor/modifier functions this way.
>[color=green]
>> private:
>> int _size;[/color]
>
>Now *that* isn't allowed. Leading underscores are reserved for the
>implementation. I suggest changing that to size_.[/color]

Not quite, there is some rules about how to use leading underscores,
and the above does not violate them as per any requirements of
Standard C++. However, it may violate other standards, or some
other convention, and besides, it's easier to not have to remember
the Standard C++ rules, so in short, the above is probably best
avoided, and instead some other convention be used (like trailing _'s)
if indeed some convention at all is necessary.
--
Greg Comeau / Celebrating 20 years of Comeauity!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Closed Thread