Sacred Code Cows

I wrote of my meeting w/ Neal Ford a few weeks ago. Today he has a long post on what he calls Eating Sacred Hamburger that goes into more detail of some of the things we discussed:

Software development cults tend to create sacred cows: habits and idioms that might have meant something at one time but only remain as baggage now. I tend to like to kill sacred cows and grill them up, with some nice lettuce, tomato, and a sesame seed bun. On my current project, we’re actively killing some sacred cows.

The main sacred cow he’s talking about slaughtering is Hungarian Notation for interfaces. You know, interfaces like IDbConnection and IHttpHandler.

Thankfully, Hungarian Notation has mostly been banished, except for one lingering, annoying location in the .NET world: the stupid “I” preface on interfaces. In fact, if you understand how interfaces should be used, this is exactly the opposite of what you want. In our application, every important semantic type is represented by an interface. Using interfaces like this makes it easier to do a whole host of things, including mocking out complex dependencies for testing. Why would you destroy the most important names in your application with Hungarian Notation telling you it’s an interface? Ironically enough, that your semantic type is an interface is an implementation detail — exactly the kind of detail you want to keep out of interfaces. I suspect this nasty habit developed in the .NET world because interfaces first came to the Microsoft world as COM (or, back when it started, OLE). It’s a stupid cow now, and should be slaughtered.

I agree 100% with this, though I’m guessing the next time I write an interface, I’ll have to go back and delete the stupid “I” because I’m so used to writing it.

The other convention he’s looking to do away with camel and pascal casing, which is convention in .NET. He’s a bigger fan of using underscores between words (which is big in the Ruby world). So far, he’s only using underscores in his test methods since they tend to be longer, such as “Verify_end_to_end_security_connectivity_to_infrastructure”. Frankly, I’m ambivalent on this one. I’m pretty good at reading camel and pascal casing and I would hope never to see a production method name like that.

So that’s two down, but there’s still an entire herd of sacred cows out there. What other ones do we need to get rid of?

Comments:

NO NO NO! No bloody underscores between words! BIG bloody annoyance! [Sound of light saber being activated] I will lop off the fingers of the first one of you who DARES to even THINK of deprecating Camel and Pascal casing in .NET code! You freaks who want to code with underscores in Ruby, I hope you, too, get run out of town on a Rail! GRRRRRR! (No, seriously, underscores are the spawn of Satan). Have a nice day! :)
Good post. I think this concept intersects with the phenomenon of "cargo cult" programming to some degree. On my team, the old timers are in the habit of setting local references to Nothing when using VB.NET. Ie, Public Sub Foo() Dim x As New Object ' Use x x = Nothing End Sub Nobody can explain how this got started and I've had some extreme difficulty explaining this is not necessary.
Come on Mike, tell us how you REALLY feel! :)
You wrote "He's a bigger fan of using underscores between words (which is big in the Ruby world)". The Ruby world got this from Eiffel and Bertrand Meyer. Just read Object-oriented Software Construction, 2nd Edition. And anyone with a modicum of knowledge knows that Ruby's inventor was heavily inspired by Eiffel and the OOSC-book. Eirik "If I can't Eiffel in heaven, I won't go."