|
Boost : |
From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-09-09 23:36:59
(responses inline)
----- 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
"Eric Woodruff" <Eric.Woodruff_at_[hidden]> wrote in message
news:038401c25859$64f44960$1800000a_at_soy...
> Yes, I know people do crazy things with their alignment and they think
> it provides significant value. In reality, you should never have deeply
> nested blocks, and blocks should be at THE MOST 20 lines, all of this
> alignment is moot when most methods are at the 10-15 line level.
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.
> [...]
> Your desired spacing method is hideous.
Beauty is in the eye of the beholder. Frankly, I find it more difficult to
locate important identifiers in an unaligned class header than in an
aligned one. But that's probably because I'm not such an advanced
programmer as yourself, and such trivial things are not obvious to me.
===> 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.
You might have some good points when it comes to the design of a development
environment, as far as spacing, and alignment, maybe even color coding,
flashing, whatever you wanted. 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'm not a big fan
of trying to express something in an unsuited environment (like a
constrained one that's using spaces to indent). For the same reason, I avoid
comments--and macros because the fall on the same plane. (I'm also uneasy
with the fact that I have to express my responses to your statements with
===>)
> Note: A good editor would force the indentation automatically in a
> block, and never let it be violated.
There are an awful lot of unquestioned absolutes in your world. Must
be nice.
===> 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, with
the help of our editors, or compilers or modeling software. It should
protect us from our laziness when creating.
> The purpose of the tabbed indentation is to show the scope,
> especially since it matters so much in C++.
I agree. And for me, the purpose of alignment is to help locate the
important parts of class declarations. Here is an example:
class foo
{
public:
really_long_return_type const& bar(int);
void baz(long, return_type const&, char const*);
};
It's a little contrived, but if I happened to know that I was looking for a
function taking a long and some other parameters, it's more work to
parse the class definition and locate the function of interest compared
to this layout:
class foo
{
public:
really_long_return_type const&
bar(int);
void baz(long, return_type const&, char const*);
};
The alignment of function names makes it easy to scan the list
quickly (which is something I do quite often, when referring to my
own interfaces). I don't suggest that everyone should code this way,
but I think it's quite fascist to insist that this is a morally
reprehensible
way to do things.
And for the record, while the identifiers in the example are contrived,
the overall situation is not. I commonly have radically differing return
type identifier lengths which would result in rather zig-zag code were
I not to align the names. Another example is inline function definitions.
While some people would say these are altogether evil, I think it a bit
fascist to insist that simple accessor functions not be declared inline,
a la:
===> 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).
class foo
{
public:
int bar() const { return bar_; }
char baz() const { return baz_; }
private:
int bar_;
char baz_;
};
I find that unaligned inlined functions are harder to read (though that
is strictly a matter of personal preference).
Dave
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk