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:

hashSet.add(sequence);

...

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?

-Bil