5

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;
Max MacLeod
  • 26,115
  • 13
  • 104
  • 132
objlv
  • 591
  • 1
  • 7
  • 13
  • 1
    Note that the compiler should complain loudly about that pattern. A better idea is to not re-invent the wheel by using the sqlite API directly; there are both 3rd party wrappers that give you higher level APIs that will make development go faster or you could use Core Data, which will give you much better integration with the system as a whole. – bbum Feb 09 '12 at 18:12
  • Thanks for the comment bbum. You are absolutely right. – objlv Feb 09 '12 at 18:20

4 Answers4

11

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];
}
...
Sam
  • 26,946
  • 12
  • 75
  • 101
5

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

ZelluX
  • 69,107
  • 19
  • 71
  • 104
  • I don't see why a zero value is any less bug prone than a random value. –  Feb 09 '12 at 17:32
  • @infact For example, if the returned value is used in a block later, or retained by some other instance, it will crash. – ZelluX Feb 09 '12 at 17:36
  • I thought they changed this in iOS 5 to automatically initialize variables to nil. – John Koerner Feb 09 '12 at 17:42
  • 2
    @JohnKoerner Variables will automatically be assigned to nil if you are using ARC. – Sam Feb 09 '12 at 17:44
  • 1
    @infact: `nil` is a safe value for an object pointer because messages can be sent to `nil` without causing a crash. Using an uninitialized variable is also ["undefined behavior"](http://stackoverflow.com/questions/1597405/). – jscs Feb 09 '12 at 18:31
0

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.

gnasher729
  • 51,477
  • 5
  • 75
  • 98
0

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

Joel Kravets
  • 2,473
  • 19
  • 16