Good programmers write good code, but what does that really mean? Countless tomes have been written on this subject, what follows is just a double distilled summary:
Design – designing means to know exactly what you’re going to implement, way before you’re actually doing it. If you lack the “sit and think” approach, your implementation will reflect it (will be poor, no matter how good coder you are). From the programmer point of view, design follows other stages like creating functional requirements out of marketing requirements, system analysis and so on. There is no good code without good analysis and design. The serialization between these steps is mandatory. Using appropriate (ALM enabled) tools can smooth the transition between different stages quite a lot, save you development time, and allows you to do more for less.
Simplicity – knowing exactly what’s in store to implement doesn’t call for simplicity. A naïve view of simplicity defines it like “you don’t do in ten lines what you can do in five”. Reality always prevails against slogans. Therefore, simplicity is a set of techniques (some coming from your data structures and algorithms toolbox, some coming from experience, that is, heuristics) helping you to write simple code. An old Roman proverb “divide and conquer” describes simplicity even better. Of course, the roots of simplicity propagate up to the design stages. Only simple code could be close to bug free.
Readability – simply put, readability means that other can read your code. A more realistic view promotes readability to the set of methods of making yourself easily understood, so others can digest your work fast so they can properly consume it and extend it. Readability is a twin of simplicity, which is a good twin of good design. Clarity (a cousin of readability) is just a particular case of readability.
Efficiency – in two words, your code be as fast and small as possible. A better definition takes more factors in consideration. Your code should not only be as fast and small as possible. Your code should actually be as fast and small as needed for a given purpose. Writing a browser in assembly would definitely make it faster and smaller, but it this really worthwhile? Same thing about many applications we build on daily basis. Even if you work on a kernel or another you have to understand that well understood and applied efficiency means that, the application performs as fast and economical as the purpose requires. A perfect example to back up this idea is “the pyramids of Egypt”. They’re great but are they structurally efficient? Just think about it… I am sure you will agree with me that they are not.
Componentness, OOP, Intuition – Componentness was first used by Anders Hejlsberg several years ago, during development of Delphi 1. Simply put, componentness is a way of creating nice buildings, made out of walls, which are made out of bricks, etc. The nice thing is that any break can be put in any wall and the brick itself doesn’t need to know about (to be designed for) a wall or another. The above analogy is about frameworks, which are made of components. Instantiating a component is like putting a brick in a wall. Please note that when you call a function (member function, method, etc) your call propagates down (to lower framework layers) versus events, which are always coming back to (propagate back up). The idea of using events is such a dramatic transformation that the only thing that comes to mind would be Exodus from Egypt. Components also have properties, usable just like trivial data fields but having actions happening behind the hood (via setters and getters). A component can also persist itself. Components can be used in RAD tools like form designers, object inspectors, because of the decent amount of meta-data (that is, extended RTTI) they contain. Some frameworks break the programming language barrier (that is, components can be written in any language and then instantiated/consumed from any other language). Other frameworks sell you cross platform (that is, they can run on more than one operating system). Regardless the main purpose, frameworks help you avoiding reinventing the wheel on daily basis, give you enough reusability and abstraction so you can get your job done in time and budget. All this simplicity you benefit from, while consuming a framework comes with a price… You’re going to say “performance”. No, it’s not that. The price is complexity. That is, good frameworks are hard to design. More comfort you get, more work it is for us to build you that comfort. Some (relatively) recent studies revealed that building OOP system (and implicitly component frameworks) could be one of the most complex intellectual activities on the planet today. That is because, beyond writing good code, framework design takes you a step further. In order to be extensible, frameworks require INTUITION! That is… Especially on the base layers, frameworks require designers with intuition.
At last but not at least, Elegance – just like beauty, elegance is hard to describe but easy to recognize. Elegance is a combination of simplicity, efficiency, brilliance, experience, good taste and pride of being “where no one has gone before”. Don’t let yourself fooled by elegance. Elegance is very easy or almost impossible. That is, it’s like a given. May we say talent? Well, yes and no… True elegance grows on a solid theoretical base, combined with decades of practice. As elitist as it may sound, elegance exists. Personal advice: “don’t push it”. Wait for elegance… Elegance will come to you at the right time and place… It is well known that a good OOP engineer needs over two years of writing OOP code on daily basis in order to write clean code. In order to write elegant code one may need several times more time… One more thing on elegance: humility is the only real life forging way to achieve it… Here is what Sir Isaac Newton used to say, by the end of his life: “I’ve seen further, because I’ve climbed on giants shoulders”. Elegance has a lot to do with his words.
