Code for readability |
 |
 |
 |
| Written by Graham Stoney | |
|
If your product is successful, someone will need to maintain it; and that means someone else will eventually need to read your code. It may even simply be you, down the track. Do that person a favour by coding for readability. Readable code tends to be more efficient than spaghetti, especially if you are using an efficient architecture and good algorithms. Readable code is generally efficient code, and much easier to optimise later than spaghetti. Don't obfuscate your code by prematurely optimising before you've actually profiled it to see where the hotspots are. Some common "optimisations" can actually slow code down; for example, loop unrolling can cause a loop which may have fitted in the top-level CPU instruction cache to blow out in size so it actually runs slower. Modern compilers do branch-prediction, and CPU manufacturers play tricks like speculative execution to limit branch overhead. Don't try to hand-optimise everything; you'll end up missing the forest for the trees. Often there are bigger gains to be made by using a better algorithm, or a more streamlined architecture. These sort of things can give a global performance improvement, whereas hand-optimising one rarely executed piece of code will have little effect. Hand-optimising everything will ensure the project runs so late that it never gets delivered. Social Bookmark this page:         
|