Tuesday, February 01, 2005

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.


Code Complexity

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.


In conclusion

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.



4 Comments:

At Wednesday, February 02, 2005 7:48:00 AM, Blogger Stan said...

Okay, this might sound mildly offensive, but I found that article to be somewhat superficial. Maybe it had something to do with the misplaced title. It said "Code ramblings on programming style" when it should have read "code ramblings on coding style". See the difference? I hope so.

I believe, as a programmer, we are first and foremost, creative thinkers. We find solutions to problems. Programming languages and such are simply our media of expression (you could compare them to an artist's brushes, or a craftsman's tools). They are a means to an end, and not an end in themselves (unless of course, you're creating those tools, but thats a whole 'nother discussion). Certainly the tools are important, but they should take second place to the concepts they express.

I believe that any "programming style" that doesn't expose simple ideas is sadly lacking. If you had simple ideas, it would be a lot easier to express them simply, wouldn't it? In my opinion, the major difference between experienced and inexperienced programmers is simplicity of expression. I believe that can only be acheived through simplicity of thought.

As for "important == interesting", all I can say is given that conditional, most situations in life would "return false" (sounds like one of those discussions of "art for art's sake"). I'd like to point out that what bores me is not being able to apply my mind (myself) to any problem I'm working on. This usually happens when I'm working with one of those "Just plug it in and push 'go' and thats it! Even an idiot can do this" technologies (no names here). Hey, as far as I'm concerned, the idiots can have 'em.

I'm an advocate of finding where u belong, because thats the ONLY place that you'll give your best. If you're interested in core network programming, what the heck are you doing in a company that develops graphics software? Do everyone a favor - find your zone, and let others who are interested in graphics take over. One man's bread...

 
At Wednesday, February 02, 2005 8:55:00 AM, Blogger Essien Ita Essien said...

uhh... Programming? Coding? I'm not so sure I SEE the difference, but uhh... you probably see something in this article which I don't, and this is the first judge of a good program - That someone else sees a use and a meaning that the original coder didn't even begin to think of.

With the previous concious deception of me own self :), I will hence say... wow! good article :).

In conclusion, burrowing from the words of a mutual friend - We're saying the same thing.

 
At Wednesday, February 02, 2005 9:02:00 AM, Blogger Essien Ita Essien said...

This comment has been removed by a blog administrator.

 
At Wednesday, February 02, 2005 9:21:00 AM, Blogger Essien Ita Essien said...

Ahh... on second thought, I think I may have seen what you mean when you say "Superficial..." , "probably because of the title". Yeah... i think saying Programming Style, may lead someone to expect a rather theoritical discourse on technical details, which is far from my intent.

I'm instead just talking about how i expect to see code, and that, as an important entity. What i'm interested in, is the thing you look at and how you go about producing it. I'm not interested in all the high theory, but just the individual actions of a good coder, collected as an actual body of knowledge.

[i'll change the title... thnx for pointing that out.]



You said:
Programming languages and such are simply our media of expression (you could compare them to an artist's brushes, or a craftsman's tools). They are a means to an end, and not an end in themselves (unless of course, you're creating those tools, but thats a whole 'nother discussion). Certainly the tools are important, but they should take second place to the concepts they express.


I say:

I agree perfectly, tho, that's probably not even what I'm rambling about in this article. What i'm rambling about cuts across programming languages, and its more (like you said about the topic, the style of coding with any language). Think about driving style for instance, it doesn't depend on the car you're driving, tho a well balanced car (like a BMW), may make you alter your driving style a bit, but generally, things like slowing down at junctions, the way you keep you hands on the steering, do you usually leave on hand resting on the gear?, do you unconciously step on the breaks ever so slightly when you change gears... if you can translate such to coding... then i'm talking about the same kind of thing.


You said:
I believe that any "programming style" that doesn't expose simple ideas is sadly lacking. If you had simple ideas, it would be a lot easier to express them simply, wouldn't it? In my opinion, the major difference between experienced and inexperienced programmers is simplicity of expression. I believe that can only be acheived through simplicity of thought.


I say:
Again... perfect agreement. Just Its not quite the topic i intended to convey (dang!!! that title, i'm even wondering if just changing the 'Programming' to 'Coding' in the title will help potray what I want to potray)


You say:

As for "important == interesting", all I can say is given that conditional, most situations in life would "return false" (sounds like one of those discussions of "art for art's sake"). I'd like to point out that what bores me is not being able to apply my mind (myself) to any problem I'm working on. This usually happens when I'm working with one of those "Just plug it in and push 'go' and thats it! Even an idiot can do this" technologies (no names here). Hey, as far as I'm concerned, the idiots can have 'em.

I say:

Now this one is interesting, because you've just helped me explain better, what i was trying to say :) . I never liked news as a kid because, it didn't fascinate my mind, on the other hand, Voltron, got me thinking... same with ThunderSub, even Atom Ant, and programs like Vision Ore, 321 Contact.

These programs allowed me to apply my mind in a way that news couldn't, and I would leave those programs to start improvising at our house. Like cut out a cardboard Voltron, and Put him into a 'Tempest Junior' i'd also fabricated.

I still say, that for individuals, by defacto, 'important == interesting'. Ofcourse as adults we know that some things MUST be done, interesting or not. I guess this is where real life gummies things up for us. baaaahhhh.


You say:
I'm an advocate of finding where u belong, because thats the ONLY place that you'll give your best. If you're interested in core network programming, what the heck are you doing in a company that develops graphics software? Do everyone a favor - find your zone, and let others who are interested in graphics take over. One man's bread...

I say:

Well... logical as this soundz, sometimes... there is the 'Daily Bread Factor'. Its not always easy to find your self in your dream environment, sometimes you'll even HAVE to create your dream environment, and as unfortunate as this may sound, not everyone is brave/courageous/cut out? enuff to do that.

On the other hand, this 'Daily Bread' must continue to roll in. This is probably why people don't work only on what they would LOVE to work on.

Anyway... thnx for pointing out the thing about the title.

 

Post a Comment

<< Home