What is this double underscore in Cocoa

Question

The single underscore in Objective-C is apparently reserved for Apple's "internal" use (and was available for use with private instance variables prior to Apple's claim). But why would they use a double-underscore in their SQLiteBooks example for the iPhone? See this snippet taken from MasterViewController.m:

+ (EditingViewController *)editingViewController {
    // Instantiate the editing view controller if necessary.
    if (__editingViewController == nil) {
        __editingViewController = [[EditingViewController alloc] initWithNibName:@"EditingView" bundle:nil];
    }
    return __editingViewController;
}

There's mention of double-underscore use on this forum as it relates to C - it's for the "compier's internal use." I guess I don't see how that's applicable in this situation.

I need a ViewController in my app that would behave much like the one in the SQLiteBooks example project but this double-underscore has me perplexed.

Answer 1

Neither the C compiler nor the Objective-C compiler treats variable names with leading underscores any differently than any other variable name. A single or double leading underscore is simply a convention and effectively forms a namespace, much like the NS prefix used in Cocoa classes like NSString.

Looking at the SQLiteBooks code, MasterViewController.m defines this static global variable:

// Manage the editing view controller from this class so it can be easily accessed from both the detail and add controllers.
static EditingViewController *__editingViewController = nil;

So my guess is that the author of SQLiteBooks uses a double leading underscore to indicate a global variable.

C compilers (and by extension Objective-C) reserve names beginning with two underscores and a capital letter for use by the compiler vendor, giving them a reserved namespace to use for global variables and functions used to implement standard libraries, or to introduce new non-standard keywords like __block.

While the SQLiteBooks code is technically valid, it's too easily confused with the reserved namespace in my opinion. If you do reuse that code, I'd recommend renaming that variable (Xcode has a very nice rename refactoring that will do it automatically for you).

Answer 2

To the compiler, underscores are treated like any alphabetic character. More generally though, underscores are usually used by language extensions or large libraries to avoid conflicts with user code.

Using underscores is problematic because lots of groups try to reserve every name with a specific combination of underscores.

Apple has traditionally used a single underscore prefix to denote a private instance variable (a common style in object-oriented languages). This was taken to imply that everyone should prefix their ivars with underscores until Apple pointed out that using an underscore in your code could create conflicts with Cocoa if Apple decide to change their headers and maybe you shouldn't. So underscore prefixes have become a "not advised" coding practice.

In C and C derivative languages, any word with double underscores preceeding and following is a non-standard language extension. See Apple's extensions like __attribute__

Trailing underscores are often added as compiler or debugger name mangled versions of original names (especially when the compiler is multi-pass) and are typically avoided so that these names remain clearly distinct from the originals. Google suffix their Objective-C local instance variables with underscores to avoid conflicts with Apple's underscores.

My advice: don't use underscores. You shouldn't be using local variables with the same name as instance variables (that's just confusing). The only potential conflict is between parameters in setter methods and the corresponding instance variables -- and you should probably prefix the parameter with a lowercase "a", "new" (or similar) since this clearly points out that the parameter is the incoming values but is not yet "the" value.

Answer 3

It's just a variable-naming convention. It doesn't do anything. It's a way for the program-writers to remind themselves, "This is a private variable."

Answer 4

It's not uncommon for compiler / library vendors to denote certain pre/postfixes as "reserved" for them. This is largely to avoid any inadvertent conflicts between types/defines/inherited variables.

The post you refer to is regarding defines, not variables. Many compilers use double-underscores for the defines they provide and rely upon.

As to why it the example code uses this style - the original author used the same coding style he likely employs in his day to day work and the potential conflict was never highlighted.

You should be fine retaining the code sample as-is, but if it makes you uncomfortable then you can rename the variable.