defensive coding practices

Question

Ever since I first wrote

if ($a = 5) {
   #  do something with $a, e.g.
   print "$a";
}

and went through the normal puzzling session of

• why is the result always true
• why is $a always 5

until I realized, I'd assigned 5 to $a, instead of performing a comparison.

So I decided to write that kind of condition above as

 if (5 == $a)

in other words:

always place the constant value to the left side of the comparison operator, resulting in a compilation error, should you forget to add the second "=" sign.

I tend to call this defensive coding and tend to believe it's a cousin to defensive-programming, not on the algorithmic scale, but keyword by keyword.

What defensive coding practices have you developed?

---

One Week Later:

A big "thank you" to all who answered or might add another answer in the future.

Unfortunately (or rather fortunately!) there is no single correct answer. For that my question was to broad, asking more for opinions or learnings of experience, rather than facts.

Answer 1

This is a simple and obvious one, but I NEVER EVER NEVER repeat the same string constant twice in my code, cause I KNOW that if I do I will be spelling one of them wrong :) Use constants, people!

Answer 2

I stopped using languages where you can do

if a = 5: print a

This has saved me tons of headaches =).

On a more serious note... I now always write the curly braces right after I write my ifs and for loops, and then fill them in afterwards. This makes sure my brackets are always aligned.

Answer 3

Always put curly braces after an if/for/while ... even if there's only one single statement after. BTW D. Crockford thinks it's better too: Required blocks

Answer 4

Returning a copy of a mutable object, i.e. a copy of an array, not the mutable object itself.

Answer 5

Always use braces:

if(boolean)
    oneliner();
nextLineOfCode();

is not the same as:

if(boolean)
{
    oneliner();
}
nextLineOfCode();

If oneliner() is a #defined function, and it isn't defined then your next line of code suddenly becomes subject to the if(). Same thing applies to for loops etc. With braces then the next piece of code never unintentionally becomes conditional on the if/for etc.

Answer 6

The top 3 defensive coding practices I employ are

1. unit testing
2. unit testing
3. unit testing

There is no better defense for the quality of your code than a good unit test to back you up.

Answer 7

Avoid unnecessary test. Example

1. if(bool == true)
2. Pointer checks if(pointer)

EDIT: if(pointer) is not readable so nowadays I prefer if(NULL != pointer)

Answer 8

Couple things:

• Yes, the 1-line blocks. Use the braces... heck, most good IDE's will make em for you.
• Comment your code after you write it, or re-read your comments if you did it ahead of time. Make sure your code still does what the comments say.
• Unit testing is a great fallback to re-reading your code.
• Always log an exception... or, NEVER catch an exception without saying so, at least in debug.

Answer 9

• always initialize variables
• use const wherever I can (without using mutable)
• avoid bare dynamic allocation of memor or other resources
• always use curly braces
• code use-cases and tests for any class before coding implementation
• turn on as many useful warnings as I can (-Wall -Wextra -ansi -pedantic -Werror at a minimum)
• use the simplest tool that solves the problem (in my current environment, that's bash -> grep -> awk -> python -> C++).

Answer 10

Personally, I dislike this defensive style, it makes the code hard ro read.

VC compiler warning level 4 will spot this (possible) error.
"warning C4706: assignment within conditional expression"

You can enable just this specific compiler warning, at any level:

#pragma warning(3,4706)

Answer 11

When comparing a string with a constant, write

if ("blah".equals(value)){}

instead of

if (value.equals("blah")){}

to prevent a NullPointerException. But this is the only time I use the suggested coding-style (cause "if (a = 1)..." is not possible in Java).

Answer 12

One of the things I always try to remember when I am in the Javascript world is to always start the return value of a function on the same line as the return key word.

function one(){
    return {
        result:"result"
    };
}

function two(){
    return 
    {
        result:"result"
    };
}

These 2 functions will not return the same value. The first function will return an Object with a property results set to "result". The second function will return undefined. It's a really simple mistake and it happens becaus eof Javascript's over-zealous Semi-Colon Insertion strategy. Semi-colons are semi-optional in Javascript and becasue of this the Javscript engine will add semi-coons where it thinks it's should be. Because return is actaully a valid statement a semi-colon will be inserted after the return statement and the rest of the function will essentially be ignored.

Answer 13

From my blog:

1. Think positive and return early plus avoid deep nesting. Instead of

   if (value != null) { ... do something with value ... } return

   write

   if (value == null) { return } ... do something with value ...

2. Avoid "string constants" (i.e. the same text in quotes in more than one place). Always define a real constant (with a name and an optional comment what it means) and use that.

Answer 14

Installed Resharper ;) Then I don't need to write "5 == a" to get warned if I did something wrong :)

Answer 15

Several suggestions for embedded C programming in the article Rules for Defensive C Programming from embedded.com.