Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼

Bil Lewis

Dr. Dobb's Bloggers

TAB Wars

April 26, 2009

I thought he was gonna take a swing at me!

My collegue was incensed over my use of spaces where he felt TABs belonged. And he was standing in my office, screaming at me. Telling me how I was ruining the
code base.

I initially pointed out that I was the one who had been pushing on
choosing a formatting schema and letting Eclipse do all the work. (I
had been roundly voted down. We do not need/want coding standards!)

His reponse was something to the effect that I shouldn't format code
that other people wrote and if nobody ever pushed the format button,
all would be well. And by the way I was going to Hell.

Good Grief!


As I look over the last few weeks of work, I notice a pattern of
avoidance emerging in my group. There was a minor panic when I
started a minor refactoring that touched a bunch of files (maybe 20
out of several thousand).

"Too big a change! Something might go wrong! It works OK now, don't
mess with it."

My reply was "But the whole reason I was asked to do this was because
we ARE having problems and things aren't working right! Look at all
this duplicate code!"

I lost.


I even lost the "equals" fight.

Seems someone had written and equals() and hashCode() method for a
mutable object. So if you changed a field in the object, it would have
a different hash code and you'd get this behavior:

sequence.setHeader(...); // typically this line will be in quite distant code
hashSet.contains(sequence) => false

I said "That's horrible! Let's either make the object immutable, or drop the
equals() and hashCode() methods."

"No! What if there's code that depends on that behavior and there's no
test coverage? Too dangerous!"


And along the way, I had a lovely discussion on the true nature of the
TAB. It was one of those "Alice in Wonderland" moments where I was
convinced that making TAB stops at four characters instead of eight
was acceptable practice. All that old code from the pre-2000 days that
assumed eight characters to a TAB stop wasn't important. Eclipse said
"Use four!" So we use four.

Looks fine in Eclipse and utterably unreadable in anything else.

I really, *really* do not care if we choose four or eight or if we use
TAB characters at all! I just want my code to be readable. I want it
to be readable in Eclipse, in EMACS, in TextEdit, everywhere.

(Why in the !%@^#&@#5 did the Eclipse folks decide to start using
four?? Why???)


The connecting tissue to all of these little anecdotes is the question
of uniformity. At what level is uniformity useful, and when does it
become excessive and burdensome?

I maintain that character definitions (e.g., TAB stops), code
formatting rules, and interface contracts ("The hashCode() method must
always return the same hash code for an object.") belong to the
uniformity level.

That wonderful thing known as "diversity" is best suited to the design
and construction of the program, and should be avoided below that.

As I see it, they did not hire me to be creative in my use of TABs and
whitespace, they hired me to write programs that analyze genomes.


What about you? 

Does your group use a formatting standard?

Do you leave in code that you know is wrong because some method might
depend on it?

Do you use TAB stops at four or eight? (or other???)

And do you wake up in a cold sweat, having nightmares about your
co-workers coming after you with a sharpened thumb drive?


Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.