The Petty Tyranny of Good Habits

The most useful general purpose tool I've ever owned is a Leatherman. It has pliers, a knife, wire cutters, two screwdriver heads, a bottle opener, a file, and a punch tool. It's great to keep at arm's reach for those occasions when I need one of those tools for a moment. It's quick and easy, even if it's not always the rightest tool.

If I wanted to make coleslaw, I could cut cabbage with it (but cutting cabbage is easier with a mandolin slicer).

If I wanted to tighten the handle of a drawer, I could use one of the screwdriver blades (though a dedicated screwdriver of the appropriate size offers more leverage).

If I had to open a paint can, I could use one of the other small blades (though that takes more work than using a real pryer).

I'm sure I could even break through rotten sheet rock with the tool if I didn't have a sledgehammer handy.

Go to a restaurant and you won't see the prep chefs shredding cabbage with a Leatherman. Go to a cabinetry shop and you won't see carpenters driving screws with a Leatherman. Go to an paint shop and you won't see the mixers opening cans with a Leatherman. It's a great tool for quick and dirty things, but it doesn't scale to professional uses.

If only programmers could exhibit the same degree of professionalism.

Consider the debate over Ugly Old Perl:

• "Why should I change working code?"
• "Isn't there more than one way to do it? Stop being so rigid!"
• "The old way works just fine!"
• "This has never failed for me before."
• "You're just a follower of fashion!"
• "You're a petty tyrant who loves to tell other people what to do."

Here's the thing. If all you have is a Leatherman and you have a really quick job you can get done in ten seconds, that's one thing. (It still helps if you know what you're doing; opening a paint can with the knife is a great way to break the tool and lose a lot of blood.) If you need to do something else, bad habits don't scale.

If you're writing a tiny program that no one but the five-minutes-in-the-future-you will ever have to read and you know all of the characteristics of user input and output and the security considerations, go ahead and use global variables. Go ahead and leave your code unfactored. Go ahead and ignore the error codes of system calls. If the sole determinant of how well you've programmed is how quickly you can get from having no program to having a program and no one never, ever, ever needs to maintain it, make as much of a mess as you want.

With that said, I know very few programs which don't need to scale for maintainability. Sure, that function you've written just now gets away with clobbering a global filehandle without any ill effect you can detect, but can you guarantee it will continue to do so while other people write other code in other parts of the program? Can you guarantee that all code called from that function will respect the global filehandle you've created?

Good habits like lexical encapsulation, checking for error codes, and avoiding all unnecessary interpolation of variables you are (at least for now) confident are always completely safe help you enforce those guarantees and keep confidence in a system as it grows and changes under the hands of other people (including future you).

That's why it's important to teach novices the safest way to program first, and then show them how to manage working with quick and dirty code. Set their habits appropriately so that their code will help, not hinder, their ability to write correct and maintainable code.