views:

147

answers:

4

So I just spent the last few hours pouring over code trying to figure out the source of a bug only to find that my error was none other than the obviously wrong but compiler accepted:

if (a = b)

where it should have been

if (a == b)

What do you guys do to safeguard against these frustrating errors? What other common "obviously wrong, but compiler won't complain" bugs should I also watch out for?

+3  A: 

many people do if(0 == var) for literal numbers, because 0 = x; is a compiler error. For if(a = b), I don't know any general solution. Edit: take GMan's advice and please don't actually adopt this style; it's ugly, hard to read, and totally unnecessarily if you just compile with warnings.


Another example of ways to avoid typos is putting braces in for/while/if blocks. I have seen:

if(x)
    doSomething();
somethingElse();

cause problems for example if the dev wasnt paying attention, had tabs/spaces screwed up so indentation was wrong or whatever. Removing the doSomething() line, or adding stuff to the if() block requires changes on other lines. Safer is:

if(x)
{
    doSomething();
}
somethingElse();
tenfour
The Yoda-conditionals :) . Personally, I don't like them, they look unnatural, I prefer just to turn on all the warnings and let the compiler tell me if I put assignments in conditionals.
Matteo Italia
Please don't actually adopt that style, it's ugly, hard to read, and totally unnecessarily. Just compile with warnings.
GMan
One of the senior developers on my team taught me that trick when I was just starting but I never took it because it always made code sound less like an English sentence when read aloud. I feel like that does more to hurt readability than it does to help prevent bugs. :(
leo grrr
+1  A: 

One common problem for me is not checking that a pointer exists (not NULL) before using it. This problem has created many unexpected breaks in my code.

Alexander Rafferty
Hopefully all the allocations done with new throw an exception when they fail, so it's more difficult to ignore such errors than with malloc.
Matteo Italia
It is not when allocations fail, it is when they never happen.
Alexander Rafferty
I honestly don't understand why this post was downvoted. He asked for other problems, and I gave one of my common ones.
Alexander Rafferty
+9  A: 

The best thing you can do is to stick with the miscellaneous -W/-pedantic options that the compiler makes available to you..

take a look here, there are many warnings you can enable to prevent many kinds of error, but you can't do anything about some errors except using yourself to prevent them :)

Jack
+1. I always start out my projects with `-Wall -Werror -Wextra -pedantic`, and I find it helps me keep my bug count down.
greyfade
@greyfade: so do I :) And then I have to make use of pragmas when integrating 3rd party code :(
Matthieu M.
@Matthieu M.: With GCC, you can set up your includes with the `-isystem` switch (as opposed to `-I`), which disables most warnings for those includes, so you get the benefits of keeping the warnings on your code without the drawback of having to wade through the crap from 3rd-party code.
greyfade
@greyfade: that seems a little overkill. Anyway at work (where I use gcc), we have a build system which automatically deduce the includes, so no chance to change the flags :)
Matthieu M.
+3  A: 

Most compilers provide options to give warnings in these situations. These are typically called "lint" warnings after the name of an early program to provide them for C source code (in the early days C compilers didn't have them built in, but they mostly do now). You might check to see you're enabling all warnings your compiler provides. If your compiler doesn't provide lint features, look into a good lint tool.

T.J. Crowder
Well, there are better ways inform me that compilers have these feature than beating me over the head with multiple alternating question and exclamation marks. If I don't know, I don't know. Thats why I came here to find out.
Faken
Your answer is perfectly good without the first two sentences. We weren't all born knowing about linters.
Michael Petrotta
@Faken, @Michael: You're both right, and apologies. I was going for collegial humor, and missed the mark a bit. Fixed.
T.J. Crowder