If you know C.

[hpn]

For about a year I've been writing a program in C, but after a few hours wasted today to locate a very insignificant and unrelated to the program's main goal bug, and looking back in time, I realized that about 95% of the time I spend on coding is actually a debugging process instead of implementing my ideas, meaning 10-15 lines real C code a day (excluding comments and empty lines), instead of 200 lines or something if I didn't spend all this time debugging. Is 95% wasted efficiency too much or I'm too stupid? Please share some experience if you have ever written something in C.

[mod]

I work on firmware.
30% code and 100% debug ^^

[neuron2]

The better you are at designing and implementing your program, and the more experienced you are, the less time you will need to spend on debugging. And debugging itself is a highly skilled art, so if your skills are shaky there, you may inflate the amount of time needed for debugging.

[Trahald]

Im in the same boat, hpn. but it is due to lack of planning. i have been programming in C of and on for more than 10 years, but i end up debugging alot. I like to just open VS and code and although it gets the job done i spend alot of time backtracking. i have to say the resulting code looks cleaner and functions more efficiently when you take a little time to think out not just your goal for the code, but the code itself.

[JohnnyMalaria]

I can sympathize with you :o

I've been writing some horrifically complex software and I find that the epic debugging sessions arise for three reasons:

1. A third-party tool has a bug that isn't documented! (I've had major headaches with software from Intel and Microsoft)

2. I didn't read the documentation properly that comes with the third-party libraries (usually Microsoft's)

3. I started coding without really thinking it through.

With 3, it's all too easy to fall into the trap of just brain-dumping your virgin idea straight to code. I have least trouble when I sit down with pen and paper, think the problem through, identify where logic will fail me etc. This is especially true with hand-coded assembler code.

I also only make small changes at a time rather than spending hours creating new code without testing it.

Ultimately, it's down to our human nature - we become careless and make silly mistakes. Thankfully, the compiler expects perfection and will detect many of them (syntax etc). Also, today's debugging tools are tremendously powerful. As with any tool, though, it takes time to learn how to use them efficiently and effectively.

[hpn]

I completely agree with neuron2 that it's an art.

Thankfully, the compiler expects perfection and will detect many of them (syntax etc).

Almost true, unless you try to debug something (perfectly valid at first sight) like this:
(gcc 3.4.5 is no good, other compilers may be more clever and fix it for you)

#include <stdio.h>
#include <stdlib.h>

int main( void )
{
int a, b;
//never run a C program from a folder called c:\forbiddenwindowsfolder\
a = 5;
b = 3*a;
printf( "3 times 5 = %d", b );
return 0;
};

[JohnnyMalaria]

Out of curiosity, I tried the above example in Visual Studio .NET 2003. I suspected the comment line as likely to be the bad actor. Here's what the compiler stated:

warning C4010: single-line comment contains line-continuation character
warning C4700: local variable 'a' used without having been initialized

Also, the color-coding in the editor showed that the line 'a = 5' was treated as a comment.

For me, one of the most common bugs I introduce is using = instead of == in comparison statements, e.g.,

if (bSomeBoolean = bSomeOtherBoolean)

instead of:

if (bSomeBoolean == bSomeOtherBoolean)

and usually when it's a compound statement, e.g.,

if ( (bSomeBoolean1 == bSomeOtherBoolean1) && (bSomeBoolean2 == bSomeOtherBoolean2) && (bSomeBoolean3 = bSomeOtherBoolean3) ).....

[Trahald]

the '\' at the end of the comment line is causing the next line to comment.

[mpucoder]

According to something I read (can't recall who or what) using = instead of == is the most common undetectable error programmers make.

[squid_80]

There's a trick that can help in some cases. Instead of putting something like "if (a==TRUE)", get into the habit of putting the constant value first i.e. "if (TRUE==a)". That way if you do slip up and use only one = the compiler will throw an error.

[Sirber]

My most common errors:

= instead of ==
; at the end of a for or an if

:D

[hpn]

.. the line 'a = 5' was treated as a comment.
Exactly. c:\forbiddenwindowsfolder\ was just a hoax. The real problem is that the next line a = 5 is simply ignored by the preprocessor, so basically you'll get 3 times 5 = something undefined, instead of 3 times 5 = 15. So trailing backslashes affect comments too. I recently had to learn it the hard way when commented something about a folder. GCC does not even warn you by default. You have to compile it with gcc -Wall, which I normally avoid, to get a short message (warning: multi-line comment). Nice to know that VS complains. My "notepad" failed to do so :D

[Ebobtron]

Something I know something about, doing it wrong.

divide by zero can be hard to find. 1 solution is to test the divisor before the division.

My down fall is character arrays as strings and pointers to them, I often forget whether I am passing pointers or data. And though I should learn to use them I avoid void pointers.

I normally don't work with debugging code written into the program, all builds are the same for me.

Debugging becomes fun.
sample windows api code:

char a[5];
get x;
sprintf(a"%i",x);
MessageBox(0,a,"value of x",0);
Sometimes I fill a routine with blank messagboxs(0,"","1",0).
A console program could just log out with stderr, I think
to see which one was the last to display before she crashed.
And as said in prior posts this normally finds a if(=) or if(); in fact the number of times is large, the if(); often takes days for me to see, though. Those hurt.

I'm chasing a couple of bugs now,

a new one (tooltips have no text displayed in the box when the program is used in windows xp with myapp.exe.Manifest file in folder to give the program the windows xp look and feel).

Old one (random crash after exit called).

good luck with yours

[HyperHacker]

It's so easy to screw up with pointers (freeing a pointer, not zeroing it, and using it again; treating a pointer to an array of struct pointers as a pointer to an array of structs; using the wrong data type, etc) and they can be such a huge pain to track down, especially since they tend to cause memory corruption which makes completely unrelated things fail. (I had a case where fclose() was crashing every second call because something not at all related to files was writing to an array incorrectly.)
Pointers are the Spiderman of programming - with great power comes great responsibility. :p

[amyangel]

Great!