Re: [boost] Re: Tabs creep back into source files

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-09-09 17:11:16

(Changed from HTML, as some email clients may have a problem with it)

> From: Eric Woodruff

> Horizontal alignment is only a relative concept, not absolute. The
> indendentation width is easier adjusted as a per-user setting when using
> tabs, where as it is inflexible when spaces are embedded as a an attempt
> to communicate the indentation. It is like trying to manually center text
vs
> letting the word processor calculate the text's placement.

> Spaces are lowlevel, tabs are highlevel.

This was really what I meant by saying that tabs tell logically what it's
about. I just didn't know how to express it. So, now that I realize this, it
was indeed a valid argument I had in that respect, after all.

> There just needs to be a standard of 1 tab per indentation, not two.

Of course.

> If you like your indentation to be further, use a wider tab. It is no
> different then specifying 3 spaces for indendation vs 4 or 8. The unit of
> indentation is all that needs to be consistent, not the method of
> implementing it.

> "
> * Developer A of library has tabs set for 4.
> * Developer B commits trivial fix. Developer B's editor had tabs set at 2,
> but converted tabs on the changed line only to spaces.
>
> It resulted in messed up source files."

> If developer B uses tabs of 2, I can't possibly see how it is messed up.
> They purposely want their tabs at 2. "Messed up" is highly subjective. If
> the standard is to use tabs, then obviously, the standard must be that the
> tabs remain in the files, and editors that translate them are not allowed.

Exactly. Like I said in my posting, it has to be done consistently, no
matter if you use spaces or tabs. If you mix it, it won't work no matter
what way you do it.

I'm glad someone else saw these points, as well. :)

And speaking of consistency (from
http://www.movement.uklinux.net/spacesconsideredharmful.html):

"The inevitable result of this, on a medium-sized project, is a horrendous
mis-mash of indentation sizes and styles. Don't stand there looking
nonchalant - you've all seen such code; in universities, in business code,
in student projects. Such chaos, and all avoidable merely by using that key
to the left of your keyboard !"

As we know, the Boost libraries use all kinds of indetation sizes, from 2 to
8, or whatever. There's no way to get the same everywhere, without enforcing
a fixed indentation size on all, which would be a bad idea, unless tabs are
used.

I can understand that, from practical considerations, with past experience,
Boost has standardised on spaces. That doesn't make these facts, as has been
given in this thread, and in that article, any less valid.

Note that the arguments in the article against tabs (alignment problems) are
fixed by using spaces for alignment, and you _still_ get the tab size you
want.

Regards,

Terje

----- Original Message -----
From: David Abrahams
Newsgroups: gmane.comp.lib.boost.devel
Sent: Monday, 2002:September:09 12:01
Subject: Re: Tabs creep back into source files

From: "Terje Slettebø" <tslettebo_at_[hidden]>

> How does this apply to tabs? More or less all editors have support for
tabs,
> and for setting the tab size. Do you mean to say that because some may
use
> Notepad to write programs, others won't be able to benefit from using the
> tab size they prefer?

No, I'm saying that just as with variable-pitch fonts, when source code is
written using tabs it's much more likely that something the author intended
won't be properly communicated because it's harder to control horizontal
alignment.

> >> - They tell logically what it's about, while spaces carry no such
> >> information.
> >
> >Huh?
>
> What I meant is that a tab is kind of like markup information in the
source.
> The tabs tell that this is indentation.
>
> As I understand, the reason for this is mostly that it's hard to check
that
> the practice is being followed. So tabs are banned, as that is easier to
> check for.

Yes. In fact it's impossible to check programmatically whether the practice
is being followed. In general you need to know the author's intention in
order to discern how things were meant to be aligned.