All code is not created equal. Learn from a master of the craft how to spot bad code and mold it into good. In the first iteration of this regular column, learn why selecting names for classes, methods, and variables is an art you'll want to perfect.
I REMEMBER WHEN MY DAD, who builds houses, told me that there's a right way and a wrong way to cut trim. The right way requires a bit more thought and a few more measurements, but it works better even if the person paying for the work doesn't immediately notice the difference. So you do it the right way-at least until you're good enough to know when to make an exception. "How did he know that?" I wondered. It was only after cutting a few lengths of trim myself, and struggling to rework existing trim, that I understood Dad's wisdom.
Even though I was a dedicated apprentice of my dad's work, I never put the time into becoming a master. Instead, I discovered that I had a passion for another craft: writing code. Like the smell of fresh oak to a woodworker, I'm drawn to a blank editor window. Consequently, I write a lot of code, and read even more. And with my passion for coding comes a desire to share what I've learned along the way, knowing that it will further hone my skills. To that end, this new series of articles is about writing good code as a craft, rather than code being merely one turn of the crank after a good design.
Responding to Change
Why focus on the craft of coding? A craft is characterized by internal standards of quality that aren't always obvious to the customer. If the code works as expected, the customer may not care about the code's internal quality. It's only when the code must be changed to make room for a new feature or to fix a bug that the cost of poorly written code becomes noticeable. And it's the ability to respond to change economically, which the customer does care about, that separates good code from bad.
If it will take until the heat death of the universe to retrofit the next feature, you're working with bad code. Where you put your curly braces and how your code ranks in terms of static metrics is largely irrelevant. What is relevant is the speed at which the code can be changed. So, to continually keep the cost of change at a minimum, we need to be thinking of axes of change all the time we're coding.
Like any skill, crafting code that can be easily understood and modified takes practice. In this series, we'll practice the craft techniques involved in writing code that tolerates change. We won't shy away from the fundamentals because they lay a crucial foundation for the other techniques. And there's nothing more fundamental about crafting good software than communication.
Call It By Name
One of the joys of being a creator is that you get to name things. It's a power graciously bestowed on all programmers, regardless of their experience. And yet picking names for classes, methods, and variables is a big responsibility because these names are the language of the software. A name laid down once in a flurry of key-strokes and left unchanged will be read many times over by those who follow. And for all of its virtues, the compiler offers no help when it comes to choosing names.
Choosing meaningful names for classes, methods, and variables is the single-most important thing you can do to make your code understandable. Simply put, you can change code that you understand in less time than code that's convoluted with cryptic and misleading names. This seems so obvious, but having reviewed a goodly amount of code over the years, and having personally struggled with the name game,