Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-03-17 10:27:07


--- In boost_at_y..., "Greg Colvin" <gcolvin_at_u...> wrote:
> From: <williamkempf_at_h...>
> > ... There are
> > five styles I've seen used, each rubs me wrong for different
reasons:
>
> Make that six.
>
> name: Also commonly used, short, readable, no conflicts.

I'm not sure I agree with "no conflicts". There are two reasons why
warts on members are useful. One is that it makes it obvious while
reading code which variables are members and which are local (global
adds a third category which some people use a second wart for). The
other reason is to avoid name conflicts:

class foo
{
public:
   foo(int bar) { bar = bar; } // this one can be handled with
                                // initalization lists
   int bar() { return bar; }
   void set_bar(int bar) { bar = bar; }

private:
   int bar;
}

There were some strange names selected in my implementation because
of this factor.

> > m_name: This makes the variable name longer and harder to read to
me,
> > even though coming from the MS world I'm very used to it. I just
> > don't like the embedded underscore here. This is awfully nit
picky,
> > yes, so when I do use warts this is often the one I use.
> >
> > mname: Fully unreadable.
> >
> > mName: Readable, but I prefer not using mix case, which I believe
was
> > mentioned in the Boost guidelines as well, though I could be
> > remembering this wrong.
> >
> > _name: As Dave pointed out this is only safe in the context of
class
> > variables. Granted, that's precisely what the wart is supposed
to
> > indicate, but it still feels wrong to use a wart that's
restricted in
> > some cases.
> >
> > name_: Don't know why, but this one really bugs me. It looks
like
> > someone just didn't finish typing out the variable name here.
>
> And name_ is commonly used in macro expansions to avoid conflicts
> with user names.

This is not reserved by the standard, though, is it? I think this
points out why warts are so vexing.

Bill Kempf


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk