Richard Heathfield wrote On 04/17/07 15:22,:
Clever Monkey said:
>>mdh wrote:
>>>K&R devote 4 exercises to Detab/Entab issues. An extremely cursory
search reveals entire religions following space vs tab
controversy. ...so, I guess the exercises are not in a complete
vacuum. My question is how often C programmers have to deal with this
issue in real life and under which circumstances?
At my shop, it has happened enough that we have an official
company-wide whitespace rule (set down by an architect after *days* of
holy wars), a corresponding vimrc file for Vim users, and a policy
where submitted changes to version control will be rejected if the
whitespace rules are not honoured.
That's a bit silly, isn't it? Why not just mandate running it through
indent as part of the check-in process?
On occasion a programmer can use unusual arrangements
of white space to draw attention to some aspect of the code
or to make some structure clearer than it might otherwise be.
Usually, this involves adjusting horizontal positions to
create vertical alignments, demonstrating a relationship.
Here's one (slightly trimmed) from one of my programs:
static const int columns[] = {
/* C1 C2 arg count watts */
-1, -1, -1, 1,
/* amps watt hours cost monthly kWh */
3, 1, 1, 1,
/* max watts max volts max amps min watts */
1, 1, 3, 1,
/* min amps power factor duty cycle power cycle */
3, 0, 0, 0,
};
It's a little table of numeric codes that control what the
program does with/to various fields in a line of input (I've
omitted the block comment that explains the encoding).
The excess horizontal space that aligns the code with
the field names is the sort of thing that often doesn't
survive automated format-standardizers. I submit that the
above would be significantly harder to read if it were
rearranged by a reformatter to produce:
static const int columns[] = {
/* C1 C2 arg count watts */
-1, -1, -1, 1,
/* amps watt hours cost monthly kWh */
3, 1, 1, 1,
/* max watts max volts max amps min watts */
1, 1, 3, 1,
/* min amps power factor duty cycle power cycle */
3, 0, 0, 0,
};
Yes, the table could be rearranged to keep the field
names close to the corresponding codes. For example:
static const int columns[] = {
-1, /* C1 */
-1, /* C2 */
...
.... but the chosen "tabular" layout is noticeably more
compact: a little over half as deep, even counting the
all-blank lines. (In the original, I get five fields to
the line and the savings is even greater still.) But
should I really be spending my time arranging my code in
reformatter-proof ways? These tools are supposed to be
my servants, not my masters!
Programmers should be free to use white space to make
their code easier to read, and some of those ways escape
the notice of most reformatters. That's why I think
reformatters should not be part of the "normal" flow of
source code creation and modification, even though they
are invaluable when you're trying to rescue a few reams
of crufty old code that's been patched into obscurity.
--
Er*********@sun .com 
