Code Ramblings: On Coding Stlye
Code ramblings: On coding style
[Due to an interesting comment by Stan, I changed this title. It was formerly 'On Programming Style']
I've been thinking a lot about how to program and program properly. I've read a lot of material about various approaches to programming, combined with the very basic introduction I was given in school (Top-Down Programming), and I’ve had to rethink a lot of things. I've come to a conclusion that the most important thing that a programmer can learn about programming is not the language, not a paradigm (OOP, Functional, etc), not even how to debug (NOTE: these are very important things), but the Programming Style.
I’ve also come to the conclusion that what eventually differentiates a rookie from a master, a code-smith from an apprentice is the very thing – Programming Style. But wait a minute. Are we really interested in style? Is it not product above style that we’re keen on? Well, I say good style gives good end result. And a code-smith with a formidably excellent and effective programming style will at any given time be much more productive than a set of mediocre programmers with mediocre programming styles. But let me not get ahead of myself.
In this article, I’m going to just ramble about programming style in an effort to bring it to fore as a stand-alone concept, not as a part of other concepts. This is actually important, as once someone realizes that there actually is something as programming style, and that it can aid your productivity, you can begin to actively seek to improve it.
An ad-hoc definition
What is programming style? I think of programming style, as everything the programmer does, in the particular way he/she does it, from the moment a problem is encountered, till the moment a version of code that solves the problem is released and throughout the lifetime of the code base. This definition encompasses language choice, solution paradigm, documentation, every single thing that will be done. It starts becoming a style when you use that process more than once, and even more so, when lots of other smart programmers adopt that same methodology.
To be very effective, your programming style has to evolve into a habit, such that it is now done unconsciously, instead of as a series of steps you're following from a company documentation manual.
Making time for important things – The lazy programmers creed
In all my writings, I especially clamor for a type of laziness. In fact it would be correct to say that I advocate certain laziness. This is the flat out unwillingness to do more than I have to do to solve any given problem. If I have two bags to carry upstairs, I WILL carry them with both my hands (hopefully, I’m powerful enough), instead of taking two separate trips. Trivial example? You’ll be surprised to what this translates to when coding.
With this in mind, allow me to say that first and foremost, I think the best programming practice is the one that frees you up to do more important things (we could also say that the best programming style encourages laziness – not slothfulness). What is my definition of more important? I think important == interesting. Why I increasingly take this stance is that usually people are more productive when they do things that they like, and those things are generally interesting to those people and to them, it is very important. Imagine a house with a youngster and his dad. His dad probably wants to watch the News (which we all know is very important. no?) but the youngster is keen on catching up with the latest Johnny Bravo flicks (ok... scratch the youngster... I’m a Bravo fan meself :D). In the scheme of things from Dad's perspective, News is more important, and you may disagree with me here, but I say, that's because he LIKES and is INTERESTED in events. From junior’s perspective, Johnny Bravo is WAAAAAYYYY so much more important, again because he likes and is interested in Johnny Bravo.
So what has this got to do with programming style? Well... programming, depending on your reasons for getting into it in the first place, can be like a door to fulfill your dreams of assistant-godhood (hellooooo?), or it can be just a means to pay the bills. For those that are aiming for cyber immortality, they usually have some specific areas of interests. This doesn't come from the first day you start programming. For instance, I’m certain that most engineer-programmer types have solved matrices programmatically, and it was mentally stimulating to do that, but as you grow and your specific strengths begin to shine thru, you begin to get fascinated by a problem area. For instance, some programmers are crazy about Application development, advancement in user interface designs, while some get something akin to a drug-induced high, when faced with writing their own OS Network Protocol drivers. (I mean, how else can you explain someone who implements an IRC chat client in Assembly? uhh... okay I confess, I want to do this too...) These various programmers are bound to regard different problem areas in a project as more interesting (interpret as important).
Let’s imagine jumping these two groups of guys to implement an IRC client for a modern GUI-drool-able OS. The usability guys will be concerned about Look feel, placement of widgets, colors, general feel of user, while the net-heads will be concerned about what they (wrongly?) believe to be the main push of the application. Both these guys if they can complement themselves will actually make a very good piece of software. More importantly though, will be if the resources working on the various parts of the project are aligned to their particular areas of interest. Of course, since they work in the same company, they probably know very much of programming and can work on any area, but if a sworn protocol-freak is solely responsible for GUI development in a project that COULD have had a true usability faithful on it, then I’m very convinced that results will be less than desirable. Maybe not glaringly so, but it will be there.
One question arises: how realistically-achievable is this? In a small programming team, the argument is that this is a fantasy that can not be indulged and that programmers should get realistic. True to an extent, but I’ll "ramble" about that at another time.
The main thing I’m about here is that the net-head that is working on a GUI project will prefer a programming style that enables him to finish the project quickly enough, so as to start on an area/project that he's been told is waiting for him and is more of his area of interest. Or to get home to his pet project (which these days is probably an Open Source project)
Identifying Programming Style
Programming style is IMHO more of an art than a precise science, as it becomes more obvious that GREAT programmers can be more likened to great artists... in a lot of ways... and a quick and dirty hack is generally more understandable if you think of it in terms of a rough art sketch. With all the subjective things flying around, it’s very difficult to have a precise definition of Programming Style. So instead of giving a precise definition, I’ll examine its end product.
A lot of beginner programmers are first intrigued by how complex things can get in their beginner programs, if they just get a little bit more imaginative. In fact, I used to play an unnecessarily-obfuscated-complex-code-segment game with myself back then. I would try to see how many tricks I could use to solve really basic problems. Of course, as maintainability becomes an issue, complexity shows itself like a not-so-good thing. Of course some areas can't do without being complex, but when complexity is the norm, not the exception, then that is one programming style that can result in some rather difficult to maintain projects. But this is not totally all I’m referring to when I say Complexity. The complexity I’m referring to is more subjective than objective, but nevertheless, it’s very important.
The “OH-NO! Factor”
As a result of programming style, I feel that if I look at a piece of code not written by me or not, and I get the feeling of "Ohh... men.... do I really have to figure out how this thing works?", then it’s probably more complex than it should be. Now I say this in a balanced way, and I’m not using myself as a benchmark. Typically idiomatic constructs can look complex to a beginner, but perhaps more than the actual coding constructs itself, you take a look at the source code and you just get a feeling. It’s like what can happen if you look at a runaway Perl programmer’s code - Your initial feelings are "OH NO!!!" (I have not said all Perl programs are like that, that's just an example). It just feels and looks complex, eventually though, if you take time to look thru it, it may REALLY NOT be as complex as you were thinking, but the time you spend looking at it, could have been well spent doing more important things (interpret: more interesting things). And don't forget that the best programming practice works to free your mind for more of these things.
This complexity for me particularly is a great deterrent. It normally takes me more mental preparation to begin to get into this kind of complex code, and already I have a bad feeling about that code. The effect? It causes me to switch of my creativity and go into damn!-just-finish-this mode. In this mode, I produce results, but I’ll be the first to admit they are not the best they could be. Other programmers may look at it and say it is good code, but I know, and like an artist critiquing his own work... only he knows what he could have done, or someone else, that has a true understanding of his potential.
What I’m trying to bring out here is that Complex Code (Code that Initially Feels Complex Just by looking at it), is badly written code, and from some limited experience, I’ve found that there are usually lots of bugs lurking just beneath the surface of these creations.
In a nut-shell, I’m saying that no matter what approach you take to programming, another programmer (who could be yourself in a couple of months time), should be able to look at your code, and not feel it is complex. If the programming style you use, results in this, then it is a good programming style. If it does not, you'll need to do something about it.
Excuse me. Do we have a problem here?
The problem sometimes is that we don't even see this as a problem. We believe, especially in small programming start-ups, that once the job gets done, it is okay. Well... when you start seeing the problem is when a couple of years down the road, you're still having the same or variants of the problems you used to have when you started. The same kind of bugs, the same kind of issues, the same kind of customer complaints (this actually shows that you have not embraced the right kind of laziness, hence you’re inventing the wheel each time you need to move over great distances).
I believe software is something that evolves, but even more than that software development is also a process that evolves. If I as a programmer keep wasting time when I encounter a problem today that I’ve been encountering in the past, then I’m definitely not evolving, and I’m a bad programmer. If this happens to a software development company, then that company is a bad company, with bad programmers. If this problem is not addressed, that company will keep having its best programmers leave them for more interesting (important), job opportunities.
Programming style should alleviate the programmer, free the programmer, make the programmer feel useful and creative not lock in the programmer. Once your programmers or you as a programmer is complaining about code base, there is something wrong with it and if that code base was created by you or your programmers in the not so distant past, that is a big alarm going off. Check your programming style. You should be churning out elegant code that works well but probably more importantly is pleasant to glance at, and also to visually debug.
No programmer wants to be caught up with boring (interpret: not interesting, not important), stuff. But bad programming style may be causing this rut. Worse, you may not know that this is the problem you're having.
Finally, I think it is paramount that every programmer and programming team should take a look at the code they are generating and ask themselves: "Are we proud of this? Does this look/feel complex? Will maintaining the code mean that we rob our programmers of valuable time for important things, and use that time to de-complexify this code?” The answers to these questions can give a lot of insight into your current productivity levels. And if the answers are not too good, this may be a pointer to change your programming style/habit.
In another write-up, I’ll take on what makes me feel a code base is complex into detail some more.
In yet another write-up, I’ll document my perception on where I seem to have found good programming style resulting from. I'll discuss my perception on buzz technology and its relation to Tradition and good programming style.