Detab/Entab( a little OT?)

M

mdh

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?
 
C

Clever Monkey

mdh said:
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.
 
R

Richard Heathfield

Clever Monkey said:
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?
 
K

Keith Thompson

Richard Heathfield said:
Clever Monkey said: [...]
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?

Or at least expand.

(For those not familiar with Unix tools, "indent" reformats C source
code, and "expand" expands tabs to spaces.)
 
B

Bill Pursell

Clever Monkey said:



That's a bit silly, isn't it? Why not just mandate running it through
indent as part of the check-in process?

On the off chance that the second question isn't facetious:
indent is often not sufficiently flexible and produces output
that is undesirable. IMO, it's best if a human makes the
final edits, but it's okay to have an automated script
reject or deny code. Within the last few months, I put a
hook script into my VCS that makes really basic whitespace
and column-width checks (eg the commit is rejected if I
have any trailing whitespace or any columns over 79
characters), and I was shocked at how much of my
code failed those simple checks. (Mostly trailing
whitespace errors.) I haven't yet attempted to mandate
compliance on anyone else, but I actually like having
the check in place. I haven't taken the leap yet and
put a hard limit on the number of lines in a function, though.
 
M

mdh

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.

thanks
 
?

=?ISO-8859-1?Q?Bj=F8rn_Augestad?=

Keith said:
Richard Heathfield said:
Clever Monkey said: [...]
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?

Or at least expand.

ITYM unexpand? ;-)
 
K

Keith Thompson

Bjørn Augestad said:
Keith said:
Richard Heathfield said:
Clever Monkey said: [...]
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?
Or at least expand.

ITYM unexpand? ;-)

Certainly not.
 
E

Eric Sosman

Richard Heathfield wrote On 04/17/07 15:22,:
Clever Monkey said:




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.
 
I

Ian Collins

mdh said:
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?
Just make sure everyone in the team follows the same rules. Often
editors hide discrepancies and you only find them when you attempt to
difference versions of the same file to see what changed. This can be
very painful.

You should also agree and stick to a line ending convention (DOS or UNIX).
 
C

Clever Monkey

Keith said:
Richard Heathfield said:
Clever Monkey said: [...]
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?
[Richard's reply did not show up for me, so I'm replying here.]

No, because humans know what good code looks like, and not all the
existing code is formatted the same way -- this is life. We can correct
that as we go along, but it makes no sense to introduce multi-line
changes for no other reason than to satisfy a formatting tool.

Whereas a coder might break formatting by mistake once, which can easily
be corrected in their sandbox. So far (i.e., several years and several
times as many major releases later) this has not been found to be a
hardship.

What if we turn the question around? Why should we add the extra burden
of running a formatting tool by hand or as part of an automated (read:
"brittle") process when we can simply mandate guidelines easily
implemented and understood by coders?

I work at a multi-language, multi-platform shop. It is up to the human
working on the code to make the best decision, which works well. Legacy
code can just stay legacy for all we care, and the occasional format
disaster stays out of the archives and is easily fixed by using any text
editor in the known universe.

When I review changes, I don't /want/ to see any changes other than
those specific to the problem or feature it addresses. I don't care
that my diff tool can be set to ignore whitespace changes -- they are
still changes and change incurs risk no matter what sort of change it is.

For the record, only a small amount of the changes we make will be C.
The Holy War I mentioned was around Java, which was solved by having our
code formatted exactly like the code shipped from Sun. Our C code is
legacy, and there is no way anyone will accept running it through indent
-- it's formatted Good Enough for now. The only choice was tabs vs.
spaces, and I don't recall what the rule is. The architect arbitrarily
chose one and state This Is The Way It Is To Be. I set my editors
appropriately (most are smart enough to simply figure it out from
context) and have never had a problem.
 
I

Ian Collins

Clever said:
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.

By whom? The tool or a warm body?
 
T

Thomas Dickey

Eric Sosman said:
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.

Most formatters (including indent) recognize special comments to
turn the automatic stuff off/on. Of course use of those are
subject to code review (another item which is off-topic here).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,434
Messages
2,571,689
Members
48,796
Latest member
Greg L.

Latest Threads

Top