Is it good practice to initialise a variable to nil?

Question

Is it good practice to initialize variable to nil ?

I'm asking that because when I run the analyzer on my project I get a warning.

 NSString *q;

    if(sqlite3_prepare_v2(database, [query UTF8String], -1, &statement, nil) == SQLITE_OK)
    {
        sqlite3_step(statement);
        selectedQuestion =[NSString stringWithFormat: @"%s",(char *)sqlite3_column_text(statement, 0)];
        sqlite3_finalize(statement);
    }

    sqlite3_close(database);

    return q; //Undefined or garbage value returned to caller

When I change the code the warning is gone:

NSString *q = nil;

Answer 1

If you are using ARC then your pointers will automatcially be assigned to nil. However, I don't believe you are using ARC in which case the pointer will have a garbage value. This is dangerous because whoever called the function could receive the result and believe the pointer points to something valid since it isn't equal to nil.

So... Yes, always initialize your pointers to nil or a valid value.

Example 1 :: Good example where assigning to nil first is not neccessary:

UIViewController *myVC = [[[UIViewController] alloc] init] autorelease];

Example 2 :: Bad example where assigning to nil first is not neccessary:

UIViewController *myVC = nil;  // dumb since next line assigns it to valid value
myVC = [[[UIViewController] alloc] init] autorelease];

Example 3 :: Good example of assigning to nil since it will conditionally get a new value

UIViewController *myVC = nil;  // :D
if (someCondition)
{
   myVC = [[[UIViewController] alloc] init] autorelease];
}
...

Answer 2

Yes. If q is not initialized to nil, it will have a random value, which may introduce hidden bugs in later execution.

Answer 3

Yes that's perfectly fine. Nil is just another way of saying this variable doesn't point to anything in memory.

Answer 4

It is a very good practice to set any variable to some defined value before it is used. Not doing so is going to cause all kinds of problems. The rest depends a lot on the tools that you are using.

A good compiler will tell you if you are using a variable that hasn't been defined before you use it or where the compiler cannot prove that it is defined before you use it. A bad compiler (or a good compiler used by a developer who doesn't know how to use their tools properly) won't do that. With a good compiler, initialisation to nil or NULL might prevent the compiler from doing its job properly. Consider this example, where you really want the code to return an NSString that isn't nil but didn't get it right:

NSString* result;
if (condition) result = @"True";
else if (otherCondition) result = @"False";
return result;

Here the compiler can warn you because you might return an undefined result. If you initialise result to nil, you still have the same problem that you might return nil in a function that isn't supposed to return nil, but the compiler cannot warn you.

On the other hand, if the value must be nil, or if nil is an acceptable value, and you plan not to set the variable to a different value in some cases, then initialising to nil is fine and good practice.

Summary: Use a compiler and set it up properly so that it will tell you if you are using uninitialised variables. If you get a warning about uninitialsed variables, fix the problem, not the warning.