Thursday, February 28, 2002

What makes clean code?

The problem of always learning more.

Every programmer remembers his or her first "big" application. By big I am referring about a project that wasn't for a class, it actually did something, and went over some magic line number that gave the creator bragging rights (such as 500 lines). More often then not these projects are not very good games. And of course not only was the point to show everyone the game, but the code as well. The code might even still be saved somewhere gathering dust. The author is proud of it, but wouldn't dare look at the code for fear of what he might find. The code of this first project is probably smeared with programming goop: badly written or out of place code. Part of what made the code so horrible was simply the inexperience of the programmer, but the other half was closely related and is something I have dubbed: learning code goop.

What is learning code goop? It is a subset of regular code goop, the left over code from attempts at solving a problem. As a developer grows their code will naturally be cleaner and more thought out, reducing the overall goop within it. Unfortunately learning code goop stays with coders for a long time (and for some developers it never seems to leave) because it comes from the constant learning of new tools and attempts at utilizing them. As a developer attempts to write an application in the "toolkit of the week" they must learn that toolkit at the same time. They may have read a book, went through a tutorial or even written a few applications in it already. But there is always something new to learn about the libraries and toolkits that are being used by the developer. When the developer wants to add a new feature to an application he must first figure out how to do it using the toolkit. He will probably try several different ways before finding a working solution. But before that happens: temporary functions with nonsense names such as try(), 1 letter variables, includes, and of course code with no comments will be created. This is so the developer can quickly try out what he thinks the documentation might be saying or what he thinks the language can do. In most cases once the new feature is complete the developer doesn't go back and cleanup the functions, variable names, and add proper comments. The new feature is complete and so it is time to move onto the next feature. One reason why the code isn't immediately gone over is that the developer has just spent a good amount of time pouring over the same tiny bit of code over and over and can probably recite it if asked. At this point in time the code is perfectly clear in his mind. Unfortunately this new feature is filled with bits of code goop making the code difficult for anyone to read. Even the original author when presented with the code in a month will probably like to clean it up.

These types of problems aren't the grand scale problems thought out before programming started, but small ones that aren't included in the design documentation. It might be as primitive as a task such as replacing b*r with g*r (* being any length of characters). An inexperienced developer might spend twenty minutes write two functions to do it when it really can be done in one line of code. I can think of countless examples of scenarios that I have seen where students attempt to figure out what can often be done in three lines of code, but there solution is much larger. The trick to avoiding the whole problem is to know the three lines of code. Of course no one knows exactly what will solve the problem and that is where the goop comes from. That is the reason why the problem is found not just in students. Unlike general programming goop that disappears as the developer matures in his/her coding skills this can stick with them for a lot longer.

Unfortunately a good programmer will only know the magic three lines of code part of the time because there will always be new features to learn. The hard part is avoiding writing goop when you are learning these new features. But how can a developer avoid learning goop?

To successfully remove goop from code a developer must do several things. First the developer must be familiar with the internals of the programming language. Not only mastering the basics, but also more advanced components. This way when faced with a simply problem they wont use a solution that shouldn't be. Next the programmer defines some sort of style guild-line to follow. In the book Code Complete the author gives many good suggestions on how to improve the readability of code. Everything from variable naming to application design. Many developers have read the book, thought it was great, but when they look at their code from the week before they can spot areas that need work. More then likely the areas of work are from learning goop and the solution is that when they are done with a little problem go back and clean up the code they had just worked on. Apply the style guides, add comments, and remove unneeded code. Even do a code review of the new lines of code. Some programmers are so eager to hit compile that they often missed such simply things a missing else statements leading to bugs further down the line.

Programming goop is something that affects most programmers. Some are able to overcome it, but many don't. Have you?

Thursday, February 21, 2002

KAudioCreator

I have created a new application called KAudioCreator. It is a front-end tool for ripping and encoding CD's. I am happy to say that KAudioCreator will be part of KDE starting with KDE 3.1.

KAudioCreator is a front-end tool for ripping audio CDs and encoding the wav files using your favorite encoder. Based upon KDE it combines the look and feel of your desktop with the power and flexibility of the command line tools. KAudioCreator is an audio file creation solution for KDE. It allows you to use whatever encoder you wish to encode your audio files while providing a comfortable GUI. KAudioCreator also provides a job control system so you can see what files have succeeded, failed and stop or cancel jobs as the application progresses.

The source for KAudioCreator is now kept in KDE's repository here.










Popular Posts