“De-Bugging” Code before Check-in
Subscribe To Our Feed | Follow Us On Twitter | Get Updates on Email
Even an expert programmer cannot claim of writing bug free code. Bugs are here to stay during a software development life cycle. But what every programmer needs to do is to test his code before the code goes into the main repository. So, programmers have different techniques to do this. Running Test cases, getting code reviewed, code walk through, running manual tests, ad-hoc tests are various things performed by people and Bang!!! code goes into the repository. Let’s consider the following psuedo-code:
char* someString = (char*) malloc(100); if(someString != NULL){ // do something }else{ // handle error condition }
Now, If you try to test the above code using the above mentioned testing techniques, you can never be sure that you have covered 100% code in developer testing. The code definitely seems to be fine handling the error condition if the memory allocation fails. But have you actually tested the error condition handling? Generally, all the automated test cases or running the code will make the memory allocation successful and the error condition will never get executed. Even the code reviewers will pass the code without any objection as the code is handling memory allocation failure. But you haven’t made sure that error handling is safe or not. The Bug might be in error handling scenario.
So, One of the best way to “de-Bug” or test your code is always to step through your code. Think that you were stepping through your code using a debugger. Now, put a breakpoint at malloc and set someString to NULL right after memory allocation is done. This will enable your error condition code to be executed and you can claim 100% coverage of testing your code before checking it in the repository.
The next word of advise is that not only error conditions, one should check all the possible execution paths in the code. Consider the following example:
int someInt = 30; char someChar = 'c'; if( someInt= 32 && someChar=='c'){ // do something }else{ // handle error condition }
If you notice, I have made a mistake in the code by typing ‘=’ in place of ‘==’ in the first part of ‘if’ statement. So, even if you run test cases or use debugger, the code will easily execute ‘if’ statement in one shot and will evaulate to true as first and second condition will always evaluate to ‘TRUE’. and hence, leaving a hole in the code. The error condition will never occur in this case. This can only be caught if while using a debugger, put a breakpoint inside ‘if’ statement, and then verify both the conditions on either side of ‘&&’ operator. This will lead you to find the anomaly in the code and hence, you’ll be able to kill a potential showstopper bug instantly.
In a nutshell, I wish to emphasize on a point is that debuggers are not meant only to be used when the defects are raised in defect trackign systems, they should be used during developmental testing of the code. I agree that this consumes a hell lot of extra time in development but isn’t it beneficial to be safe in the beginning rather than wasting time on these small issues after the software is released and have already translated into bigger crash bugs.
© Safer Code | “De-Bugging” Code before Check-in
|
Liked this post? Get FREE Updates Subscribe to RSS feed 
|
Related posts
Tags: bugs, C, crash, debugging, Efficiency, Languages, programming, safety and security, Security, testing
