About | Forum | Gallery | News | Order the XPT | Products | Rants | Security | Services | Workshop
Home » Workshop » Developer

Bugs & Bloat

Bugs and bloat are very much a part of the same equation.


Get It

Try It

Reduction in bloat is often a side-effect of ridding an application of its bugs. Discovering both bloat and bugs comes about by reviewing one's code - even when one is reasonably satisfied that the code already works.

There are no awards for getting code to work; that is a requirement of the profession. If you can't get your code to work, then maybe you aren't a programmer. And when it finally does work, it might be time to have a small celebration, but it is definitely not time to 'call it a day'. Your work has just begun.

Getting into the habit of reviewing code you are convinced will work can be a difficult discipline to assimilate, yet if you are going to produce robust code then you must overcome this hurdle. Your code cannot ever be tested completely, and so any time you spend reviewing and testing it is time well spent. Corporate constraints to get things to market should not be so severe as to eliminate this vital phase of your work.

There are several milestone steps in getting good code into production:

  1. Read the requirement spec. This goes without saying.
  2. Try to understand the requirement spec. Try to figure out what the author is really trying to say. Starting your coding already now instead, like a secretary taking dictation, is a sure-fire way to invite catastrophe.
  3. Try to figure out what the customer really needs. Don't second guess the customer, but assume the customer is not as finely honed at logic as you are (or should be). A requirement spec might be filled with spaghetti thought; try to unentangle it.
  4. Code it. Once you've organized the assignment into its bare logic basics, you should proceed. But don't do it all at once, unless it is a trivial application. Remember that statistically 90-95% of the time spent on development is attributable to just getting the code to work; reduce this factor by writing your code from the very beginning so you can immediately test it, and by thoroughly testing each and every increment.
  5. Get it to work - then archive the code securely and take five. Once you have the code working, pop a top and breathe out. At least at this point, if you never have time to go back to it again, you have completed your assignment - sort of. Relax a bit before proceeding. Clear your head. For your entire perspective changes from this moment onward. And never never never go back and edit your original copy of code that works! Don't be so stupid!
  6. Look at it like a computer would. Programming is essentially a translation assignment. First draft translations are clumsy, even more sophisticated translations may be lacking. Once you are able to realize the idea in 'computerese' see what the computer thinks of it. It is very important that you realize that you must learn to think in at least three totally separate languages: your customer's language, your programming language, and the computer's language. Language and thought go hand in hand. Once the idea is understandable from the perspective of the computer itself (and provided you have learned to 'think' like a computer and not only pay token homage to its language) a number of things will be immediately obvious to you.
  7. Let the 'computer' in you reorganize the code. Once the computer has understood what the code is all about, it will immediately be apparent how the code can be better organized. If you've ever been in a situation where you've talked with someone through an interpreter, you'll immediately recognize what this is all about.
    'Mr. Batswami says he is happy to know you again!'
    'Huh? 'Know me again'?'
    'Why yes! Mr. Batswami knew you in 1998, and now he knows you again!'
    'Oh you mean he's happy to meet me again? Oh! Oh!'
    Translation, i.e. programming, is not a process of finding corresponding words; it is the process of finding a corresponding thought. Computers don't think as humans do - if you are a programmer then you should already know that - and your task is to find out how a computer can, when presented with your idea, express it most succinctly.

If you are developing a Wintel application, then remember that Intel processors are severely limited, and remember why. x86's don't have an armada of general purpose registers, so Steve Johnson's idea of minimizing RAM access has its part here. Whatever you can do with your present CPU register contents is going to run faster and leaner than corresponding code spiked with references to global variables and/or code that wantonly creates too many local variables. If you can reuse local variables for new assignments, do it - remember, the compiler cannot figure out what you are up to, and will logically assume that if you've declared two separate local variables, it's because you need them - and need them to be separate. Yet every local variable is a place of storage on the far side of the stack and creates additional overhead.

You won't need the register keyword much anymore; you should let the compiler determine which if any of your local variables should be given immediate register storage. Yet the exact order in which you carry out the instructions in your code can play a part in the compiler's optimization. And never attempt to initialize any array or structure on the stack: Microsoft compilers will offer this opportunity, but it is not straight C and the overhead is enormous. Set these variables in the code itself.

You don't have to get uptight about global variables (as you should not get uptight about goto) but understand that even if your modern CPU can access a variable in RAM in as few clock cycles as it can a register variable, it still takes more code. So yes, if your empirical testing does not prove otherwise, pass the information as function arguments rather than letting each and every function run down to the corner to get the information itself.

Never be afraid to completely dismantle the application and start anew. As long as you have a working version of the code securely archived, and as long as you have the time, you have nothing to lose - and everything to gain. Perhaps your initial idea was off-target. Perhaps you've come upon a better interface, or a better solution to the requirement spec. Don't balk at the opportunity, but investigate it fully.

And if you do take the time to follow all the above advice, a remarkable thing will happen to you along the way - you'll get rid of a lot of bugs and bloat.

About | Buy | News | Products | Rants | Search | Security
Copyright © Radsoft. All rights reserved.