Programming is an art, not a science. Some people might baulk at the idea that it’s an art, but it is certainly a craft.
Bad programmers write bad code, great programmer write elegant code.
I have read a lot of code in my time. And some of it was so badly written that it was scary.
Conversely, it is a pleasure to read code that is so well-written that it is elegant.
Writing a program involves making dozens (or hundreds) of decisions. It involves solving lots and lots of puzzles. Solving puzzles is one of the great joys of programming. There always multiple ways to tackle each puzzle. And each decision is an opportunity to move towards elegance, or towards chaos.
I don’t think everyone can be a good programmer. I have worked with people who wrote chaotic code. This code was a nightmare to read, and a nightmare to maintain/enhance.
Some people have the gift of finding the elegance, and some do not. That’s what separates bad programmers, from good programmers, from great programmers.
In my opinion, a great programmer would not be happy just to get a program working. They would not be happy until the program is elegant.
I think it’s acceptable to write a small piece of inelegant code while you’re trying to get something working, or to understand it fully. But once you have that clear picture, you should always rewrite/refactor for elegance.
A simple example of the decisions which a programmer needs to make is when functionality should be delivered inline, when it should be moved out to a separate function/method, and when a new Class is needed.
Elegant code should be easy to read and understand. Badly written code can be a nightmare to understand!
First Example
I have a book called “Java Examples in a Nutshell” (written by David Flanagan) which I cannot throw out (even though it is dated – my edition was written in 1997) because the code is so elegant. Each of the programs is as simple as possible, while illustrating the technique in question. Almost all of them have a “main” method and most of them process simple argument so that they can be called from the command line. One, for example, is called “SimpleProxyServer” and it illustrates a simple web proxy which has one thread for passing on outgoing content, and another for passing on incoming traffic.
Second Example
This is a link to some Java code which implements the Asteroids game as a Java Applet (it was written a long time ago!)
It is a very faithful recreation of the original game and I think the code (although there is quite a lot of it) is very nicely written and very easy to read.
The main look contains the following:
updateShip();
updatePhotons();
updateUfo();
updateMissle();
updateAsteroids();
updateExplosions();
Makes sense right?!
Aside from the main Class, there is only one other one: “AsteroidsSprite”. This is used to manage all of the “vector graphics”-style objects.
The Class has a method called “isColliding” which takes one argument which is another AsteroidsSprite. So you can easily ask any AsteroidsSprite if it is colliding with any other AsteroidsSprite. Simple as that.
And there is a method called “explode” which takes an AsteroidsSprite as an argument. It creates a set of AsteroidsSprites, one for each line in the original object. And then those AsteroidsSprite are added to an array called “explosions” and those lines move and fade as they would have in the original game.
In the hands of a less capable programmer than Mike Hall this could have been a real mess. But it’s not. It is elegant.
Conclusion
The difference between a mediocre programmer and a great programmer is that the latter can make a series of decision which allow him/her to write elegant code.