[boost] Re: Tabs creep back into source files

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-09-10 00:54:50

"Since I am my own biggest client, I don't find the argument for hiding
the implementation that compelling.  In the vast majority of cases, those
accessors will never change, and even if they do, I don't code to their
implementation anyway, despite the fact that I can see them plain as
day. "

There needs to be a way to specify the name of the accessor when defining a
class attribute, this way you can be protected from yourself. Too many times
I've slipped into using the attribute directly, and gotten into some kind of
trouble, where the non lvalue of the accessor would have been very useful.

----- Original Message -----
From: David B. Held
Newsgroups: gmane.comp.lib.boost.devel
Sent: Tuesday, 2002:September:10 1:51
Subject: Re: Tabs creep back into source files

"Eric Woodruff" <Eric.Woodruff_at_[hidden]> wrote in message
news:04e001c25883$b42f6440$1800000a_at_soy...
> ----- Original Message -----
> From: David B. Held
> Newsgroups: gmane.comp.lib.boost.devel
> Sent: Tuesday, 2002:September:10 0:11
> Subject: Re: Tabs creep back into source files
>
> > I almost never align inside function bodies.  However, I do often write
> > nested classes, and sometimes these are a few classes deep.  I find
> > that aligning class definitions makes it very easy to locate items of
> > interest, since this is the part of code that I refer to most often.
>
> I don't know what you mean by never, I assume you indent inside the
> scope of a conditional or loop block.

Ah.  I was distinguishing between indentation (beginning of line), and
alignment (middle of line).  E.g.

void foo()
{
    // Indented code
    int i = 5;                // Aligned comments
    double d = 4;        // Comment
}

> Well I tend to think that learning the capabilities and interface of a
> class is important before evening beginning to attempt to use it. I
> don't make so many double-takes on the class interface once I've
> settled on a design that incorporates it.

Well, I don't have that luxury, as I'm talking about class interfaces that
I create myself, and whose final interface is not known in advance of
its usage.  I wish I were precognitive, as that would make programming
much simpler, but I'm afraid that I'm limited to good ol' fashioned
iteration.  That means looking back to see how I defined some class
interface, so I use it correctly.  It's hard to learn an interface that
doesn't
fully exist yet.

> [...]
> There could be a lot of research in that area (and probably is), but right
> now, when it comes down to it, I prefer to have clean, minimalist code
> in the reality that we can work in.

I find it's not that difficult to align code in the style I use, and once I
do it,
it makes it a lot nicer to use.  Same with comments, especially when I
come back to code later (and I always end up coming back to code
later).

> I'm not a big fan of trying to express something in an unsuited
> environment (like a constrained one that's using spaces to indent).

As a big fan of character-based terminals, I have no bias against using
spaces for layout. ;)  Write yourself an ANSI BBS, and you will have
a new-found respect for the humble space.

> The world is what you make of it in this case. When it comes to software,
> it can be almost anything you need it to be, so you should keep your eye
> out. It's about picking a paradigm and using it consistently,

Which is what I do.  And it happens to involve spaces. ;)

> with the help of our editors, or compilers or modeling software. It should
> protect us from our laziness when creating.

Unfortunately, an editor I use quite often is not very smart about layout,
period (despite having a poorly named "smart tabs" option).  I'm talking
about the editor in BCB, which, while fairly weak in quite a few areas,
is convenient because of the way it integrates with the IDE and
debugger.

> [...]
> Not fascist, but consistent. Consistency is important--sure there
> are exceptions. Anyhow, your accessors should still have the
> implementation removed from the header (unless you're using a
> template where you have to give in and include everything during
> preprocessing).

Since I am my own biggest client, I don't find the argument for hiding
the implementation that compelling.  In the vast majority of cases, those
accessors will never change, and even if they do, I don't code to their
implementation anyway, despite the fact that I can see them plain as
day.  And their stability does not force recompilation of files, either.
In fact, it actually results in slightly faster compilation, because they
often end up in precompiled headers.  So even though the
implementation file might get recompiled, it doesn't have to read the
accessor bodies, because they have already been parsed.  Of
course, this is a trivial gain, but at least it's not a loss.

Dave

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost