Of Software Coding Styles

Other Articles by Dennis W. Forbes - 2001-08-29

Dennis Forbes


Credentials and Software Development

Software development is unlike almost any other intellectual field - No matter what self-proclaimed experts will try to tell you, the reality is that some people have brains that are "wired" for advanced software development, yet others don't. Some people can enthusiastically leap into a giant heap of unknowns and come out with a smile on their face and a solution to their problems (a core requirement for software development: If all you have is a hammer and everything looks like a nail then you will be a burden to your project), while others spin aimlessly until they can get someone else to figure it out for them. Some people have an "instinct" for designing complex structures, and yet others can only go by what the latest "Visual Basic For Dummies" book taught them (ah, the many n-tier arguments from people who have no comprehension of the reasoning for the various tiers). Software development is very much like professional sports or art: Develop the most comprehensive curriculum covering decade spans and you still won't make a world-class artist or professional athlete out of someone who wouldn't be otherwise, and by the same token you won't make a world class programmer. The reason I mention this is because of seeing recent HR trends to "dumb down" software development into nice square little boxes that can be classified like many other positions: "He's go a 4-year CS...oh, but he didn't take the .Eng option! Looks like he's only a cat3! Jimbo, that dumb guy who hasn't successfully coded anything in the four years in the company lived in his parent's basement while acquiring his PhD, so clearly he is cat.6 material! Give that man a raise!"

Of Software Coding Styles

Something I have faced countless times as a software developer is absolutely idiotic debates on what qualifies as good and/or bad code, and what are the practices of an industrious, quality programmer versus a crazy anarchist programmer. While occasionally there are actually some good points being raised by clever people who really thought it through, generally these suggestions are the bane of idiots who believe that software development is something that needs to be dumbed down. I think this is best exemplified by the fact that the general reasoning behind most coding "best practices" is the old "If someone glanced at your code they might misinterpret and not fully understand what it's doing". The irony in that statement, in a nutshell, is that it actually exemplifies the worst coding practice of all: Glancing at code and making assumptions. Many failed projects were the result of someone who foolishly believed that they could just glance over someone's code and make assumptions, but as you know when people assume that just makes an ass of you and me...bah...the point is that the facts are the software development isn't a cakewalk, and while we strive to make code as clear and logical as possible, if the metering stick is the old "glance" meter then it is pure wasted effort that is likely degrading the true quality of code.

So let's get something out of the way immediately: If your reasoning for a certain coding style is that it makes it easier to understand it at a glance then you are terminally misled and may all your projects fail miserably. NEVER believe you have any right to modify, comment upon, or even ponder over code which you have not thoroughly analyzed and which you fully understand[*]. If you are confused by early returns, breaking out of loops, gotos, or any other supposed evil of software development, then please get a different career!

The Moral High Ground

Now normally I don't get overly irritated by people who want to crusade for their particular coding practices, but every now and then I meet up with a moral high grounder. These people can't simply accept that some of us think that our code is cleaner when we do parameter checking early and do early returns (rather than going 14 levels deep in conditional statements just to check the parameters), or that that complex structure communicating with hardware actually requires a goto (ooooh!  evil!) to make the execution flow more logic: No to them it is a moral issue. Early returns, you see, are "lazy". Gotos are "evil". while (TRUE) is an act of Satan. Putting { at the end of the line is pure anarchy in the face of all that is good. Moral high grounders defend the way they like things done not as a subjective "let's agree to disagree" issue, but rather as a "my way is the right way, and your way is the way of lazy, untrained programmers". I will confess that it is enormously irritating to be faced by a moral high grounder, and I think most serious programmers out there will agree with me on this: They are the devil representing pure evil.

*- This brings up one of my gripes with the claims of most open-source enthusiasts: The idea that if you have the source then you can simply "scratch your itch" and modify whatever you want. The reality is that most modern projects are MB of source code comprising many tens or hundreds of thousands of lines of code, and the interrelationships are convoluted and complex. Unless you're changing a constant string to call it "Jimmy Linux" on bootup, or something inane like that, it is very unlikely that you will scratch your itch without a significant investment of time and hence effort.


Other Articles By Dennis Forbes