Every programmer, like every artist, develops a personal programming style. That happens despite all the theory computer science is trying to push on us.
Yes, the theorists would like us all to adopt the same style. This is supposed to help reusability of code, as well as make it easy to work as a part of a huge programming team.
To that theory I say: Bah, humbug! Just look at Miscrosoft and tell me how efficient is the code produced by huge programming teams.
Programming is a creative process done by creative minds. It cannot be dictated by boards of directors, at least not without disasterous results.
A creative mind is independent and creates its own style.
That said, let me describe my own style which took several decades to shape up to its present form. I call it hardwareable programming. It is, in my opinion better than OOP. Your opinion may differ, which is perfectly fine by me. I'm not trying to tell you what to do, I'm only describing how I do it.
So, how did I come up with the idea of programming hardwareably?
To start with, as much as we programmers hate to admit, anything that can be done in software can be done in hardware better.
Now, I am not saying it should be done in hardware, I'm only saying it can. Indeed, in most cases trying to convert software into hardware would be foolish: Hardware costs much more to develop than software, and once it is done, hardware is not easy to modify.
Nevertheless, historically much of the hardware started as software. For example, in early days of data communications there was no such thing as a UART. Its functionality was achieved in software. But as the same functionality was needed by more and more software, it was converted into the hardware we now know as the UART.
Hardwareable programming style is independent of the programming language. It is a matter of attitude: As much as possible, I write every routine as if I expected to redo it in hardware sometime in the future.
That involves adjusting my programming style in several ways:
- First of all that means that the hardwareable routine is completely self-contained. Its only interface with the outside world is in accepting parameters and returning results.
Secondly, it takes a small number of parameters. Hardware designers always manage to work with a small number of parameters, not because they want to, but because it is impractical to design a chip with hundreds of I/O pins. And if they can do it, why couldn't I?
If the above seems impossible, I break the routine into several routines which do not depend on each other. KISS, in other words.
Next, I make sure there is no randomness. That means the result of the routine is always a function of its parameters and nothing else. In other words, the same parameters produce the same result every single time.
Last but not least, I group related routines, and place each such group into a separate library. Under Windows that means a DLL, under Unix a library.
Naturally, any meaningful program has to have input and output. It has to interact with the operating system. But I place all that into the main executable. It allocates and frees memory as needed, it uses pointers, it parses the input, converts it to parameters by value, passes them to the routines, gets their results and formats the output.
Obviously, the main executable does not use the hardwareable style. But I only use the main executable to connect the operating system or the program user with the hardwareable routines.
Although I have never converted my routines into hardware, nor do I generally expect to, I find this programming style extremely efficient.
It allows me to use various optimizations. For example, if a routine is to be called millions of times (not unusual since I often work with bitmap graphics--for an example, visit http://www.redprince.net/pixie/), I typically start by finding all possible parameters in advance and call the routine to build a LUT for all possible values. Then I simply look up the value in the LUT millions of times. That is much faster than calling the routine repeatedly.
This style gives me a lot of flexibility. Because each routine is simple, it is easy to maintain. Because it is in a library of related routines, I can often reuse the same routines in different programs. Because the routines make no system calls, I can use the same routines in my Windows programs and in my Unix programs.
All in all, while this style requires some serious thought at the initial stages of programming, it makes my life much easier overall.