Naming of private functions

[Phlip]

Re: Naming of private functions

Cy Edmunds wrote:
[color=blue][color=green]
> > Anyone see the benefits?[/color]
>
> I don't.[/color]

Any esthetic style guide, even a screwy one, if followed, is better than
none.

--
Phlip

http://www.xpsd.org/cgi-bin/wiki?TestFirstUserInterfaces

[Jonathan Turkanis]

Re: Naming of private functions


"Phlip" <phlip_cpp@yaho o.com> wrote in message
news:iwEUb.3233 3$yy3.23828@new ssvr33.news.pro digy.com...[color=blue]
> Cy Edmunds wrote:
>[color=green][color=darkred]
> > > Anyone see the benefits?[/color]
> >
> > I don't.[/color]
>
> Any esthetic style guide, even a screwy one, if followed, is better[/color]
than[color=blue]
> none.
>[/color]

How about this one: member functions must have names with strictly
alternating uppercase and lowercase letters.

Jonathan

[Victor Bazarov]

Re: Naming of private functions

"Jonathan Turkanis" <technews@kanga roologic.com> wrote...[color=blue]
>
> "Phlip" <phlip_cpp@yaho o.com> wrote in message
> news:iwEUb.3233 3$yy3.23828@new ssvr33.news.pro digy.com...[color=green]
> > Cy Edmunds wrote:
> >[color=darkred]
> > > > Anyone see the benefits?
> > >
> > > I don't.[/color]
> >
> > Any esthetic style guide, even a screwy one, if followed, is better[/color]
> than[color=green]
> > none.
> >[/color]
>
> How about this one: member functions must have names with strictly
> alternating uppercase and lowercase letters.[/color]

Do you consider the underscore to be an uppercase or a lowercase letter?
What about them digits?

[Jonathan Turkanis]

Re: Naming of private functions


"Victor Bazarov" <v.Abazarov@com Acast.net> wrote in message
news:4GEUb.1021 80$U%5.519842@a ttbi_s03...[color=blue]
> "Jonathan Turkanis" <technews@kanga roologic.com> wrote...[color=green]
> >
> > "Phlip" <phlip_cpp@yaho o.com> wrote in message
> > news:iwEUb.3233 3$yy3.23828@new ssvr33.news.pro digy.com...[color=darkred]
> > > Cy Edmunds wrote:
> > >
> > > > > Anyone see the benefits?
> > > >
> > > > I don't.
> > >
> > > Any esthetic style guide, even a screwy one, if followed, is[/color][/color][/color]
better[color=blue][color=green]
> > than[color=darkred]
> > > none.
> > >[/color]
> >
> > How about this one: member functions must have names with strictly
> > alternating uppercase and lowercase letters.[/color]
>
> Do you consider the underscore to be an uppercase or a lowercase[/color]
letter?[color=blue]
> What about them digits?
>[/color]

I interpret my rule to outlaw underscores and digits. I'm going to try
it tonight. I'll let you know how it turns out.

Jonathan

[E. Robert Tisdale]

Re: Naming of private functions

Phlip wrote:
[color=blue]
> Cy Edmunds wrote:
>[color=green][color=darkred]
>>>Anyone see the benefits?[/color]
>>
>>I don't.[/color]
>
> Any esthetic style guide, even a screwy one, if followed,
> is better than none.[/color]

aesthetic or esthetic

ADJECTIVE:
1. Relating to the philosophy or theories of aesthetics.
2. Of or concerning the appreciation of beauty or good taste:
the aesthetic faculties.
3. Characterized by a heightened sensitivity to beauty.
4. Artistic: The play was an aesthetic success.
5. Informal Conforming to accepted notions of good taste.

NOUN:
1. A guiding principle in matters of artistic beauty and taste;
artistic sensibility: “a generous Age of Aquarius aesthetic
that said that everything was art” (William Wilson).
2. An underlying principle, a set of principles, or a view
often manifested by outward appearances or style of behavior:
“What troubled him was the squalor of [the colonel's] aesthetic”
(Lewis H. Lapham).

"Beauty is in the eye of the beholder."
"There is no accounting for taste."

[Phlip]

Re: Naming of private functions

Jonathan Turkanis wrote:
[color=blue][color=green]
> > Any esthetic style guide, even a screwy one, if followed, is better[/color]
> than[color=green]
> > none.
> >[/color]
>
> How about this one: member functions must have names with strictly
> alternating uppercase and lowercase letters.[/color]

tHaT's NoT eStHeTiC.

--
Phlip

http://www.xpsd.org/cgi-bin/wiki?TestFirstUserInterfaces

[Jonathan Turkanis]

Re: Naming of private functions


"Phlip" <phlip_cpp@yaho o.com> wrote in message
news:KhFUb.3233 5$FO3.1657@news svr33.news.prod igy.com...[color=blue]
> Jonathan Turkanis wrote:
>[color=green][color=darkred]
> > > Any esthetic style guide, even a screwy one, if followed, is[/color][/color][/color]
better[color=blue][color=green]
> > than[color=darkred]
> > > none.
> > >[/color]
> >
> > How about this one: member functions must have names with strictly
> > alternating uppercase and lowercase letters.[/color]
>
> tHaT's NoT eStHeTiC.
>[/color]

eVeNsCrEwY?

Jonathan

[Daniel T.]

Re: Naming of private functions

Derek <me@nowhere.spe cial.com> wrote:
[color=blue]
> The company where I work uses a naming convention that I have
> never used before. They use mixed-case letters for public
> member functions, but lower-case with underscores for the
> rest, like this:
>
> class Foo
> {
> public:
> void somePublicMembe rFunction();
> protected:
> void hello_i_am_prot ected();
> private:
> void this_one_is_pri vate();
> };
>
> The other developers swear that this convention makes code
> easier to understand, but not one of can give me a concrete
> justification.
>
> Incidentally, in my previous jobs I always used the same
> convention for all member functions quite happily, but after
> several months of using this new one I'm still not convinced
> it adds value.
>
> I understand that private *data* members deserve a trailing
> underscore or m_ prefix to differentiate them from local
> variables or function arguments, but the need for this
> convention is not clear to me at all.
>
> Anyone see the benefits?[/color]

It's a stretch, but here it goes... Private member-functions need not
worry about checking the class invariant nor ensuring it upon exit,
public member-functions do. Giving them different naming conventions
might be useful to show this from within the source file without having
to check the header. However, if I'm right, then making protected
functions the same as private doesn't necessarily make sense, many of
them must insure class invariants as well... And of course, if none of
the programmers know that this is the justification, then the naming
convention isn't doing its job anyway.

[Risto Lankinen]

Re: Naming of private functions


"Phlip" <phlip_cpp@yaho o.com> wrote in message
news:XQxUb.3225 1$g32.11813@new ssvr33.news.pro digy.com...[color=blue]
>
> that code duplicates no behavior?[/color]

.... that no code duplicates behaviour, you mean? :-)

- Risto -

[DeMarcus]

Re: Naming of private functions


There's nothing wrong with making things even more clear and readable.
You may have a different oppinion than your collegues what's clear and
not, but to me it sound like a big mistake trying to change a comapany's
coding convention unless you're hired for that reason. There's a lot
of other interesting tasks to take care of than reinventing the wheel,
at least according to all members of a company board.

You may have a point though, and it could be worthwhile have a look at
it when a completely new and independent project is upcomming, but don't
harass your poor project manager with such small things. He's trying to
survive day by day making the CEO pleased.

Don't take me wrong. Standards are good, everyone should have one. ;)


Best Regards
Daniel Marcus





Derek wrote:[color=blue]
> The company where I work uses a naming convention that I have never used
> before. They use mixed-case letters for public member functions, but
> lower-case with underscores for the rest, like this:
>
> class Foo
> {
> public:
> void somePublicMembe rFunction();
> protected:
> void hello_i_am_prot ected();
> private:
> void this_one_is_pri vate();
> };
>
> The other developers swear that this convention makes code easier to
> understand, but not one of can give me a concrete justification.
>
> Incidentally, in my previous jobs I always used the same convention for
> all member functions quite happily, but after several months of using
> this new one I'm still not convinced it adds value.
>
> I understand that private *data* members deserve a trailing underscore
> or m_ prefix to differentiate them from local variables or function
> arguments, but the need for this convention is not clear to me at all.
>
> Anyone see the benefits?[/color]

[jeffc]

Re: Naming of private functions


"Derek" <me@nowhere.spe cial.com> wrote in message
news:bvu5kn$10g 8aa$1@ID-46268.news.uni-berlin.de...[color=blue]
>
> The other developers swear that this convention makes code
> easier to understand, but not one of can give me a concrete
> justification.[/color]

That's because chocolate is better than vanilla, even though I can't
actually prove it.

[jeffc]

Re: Naming of private functions


"Derek" <me@nowhere.spe cial.com> wrote in message
news:bvu79k$118 f4f$1@ID-46268.news.uni-berlin.de...[color=blue]
> My goal wasn't
> to solicit a psychic reading; just to possibly hear from
> someone who can offer an objective justification for this
> peculiar naming scheme.[/color]

There isn't one.
[color=blue]
> I can't see the benefit either. As for why they keep using
> it, my theory is that it's a misguided convention (akin to
> that used to differentiate access for data members) that
> got used, gained critical mass, and now everyone keeps
> doing it for no reason other than to keep the code looking
> consistent. :)[/color]

Consistency IS an objective reason to use something.

[Cy Edmunds]

Re: Naming of private functions

"Jonathan Turkanis" <technews@kanga roologic.com> wrote in message
news:bvv4lj$11f 6nj$1@ID-216073.news.uni-berlin.de...[color=blue]
>
> "Phlip" <phlip_cpp@yaho o.com> wrote in message
> news:iwEUb.3233 3$yy3.23828@new ssvr33.news.pro digy.com...[color=green]
> > Cy Edmunds wrote:
> >[color=darkred]
> > > > Anyone see the benefits?
> > >
> > > I don't.[/color]
> >
> > Any esthetic style guide, even a screwy one, if followed, is better[/color]
> than[color=green]
> > none.
> >[/color]
>
> How about this one: member functions must have names with strictly
> alternating uppercase and lowercase letters.
>
> Jonathan
>
>[/color]

Good point. Although I generally prefer

mY cAPS lOCK kEY iS iN tHE wRONG pOSITION

style.

--
Cy

http://home.rochester.rr.com/cyhome/