Theocacao: Breaking My Own Rules

Breaking My Own Rules

Although it would seem to violate the two recent Cocoa Dev Central style tutorials and the official guidelines on which the articles are based, I've been using a new strategy (in DataCrux, anyway) for naming variables.

The gist is that if the type of a variable is a C primitive such as int, float or a null-terminated string, I use the more traditional C naming conventions, like this:



item_count

item_buffer

If the variable represents a bonafide object, I use the more typical convention:



elementName

elementKeyPath

This makes it easier for me at a glance to see what's an object and what's a primitive, in particular when dealing with null-terminated strings versus NSStrings.

This is sort of an experiment in-progress and I may change my mind on this tomorrow. I also feel compelled to qualify it with "do as I say, not as I do" to anybody reading the style tutorials. :)

Breaking My Own Rules
Posted Dec 16, 2004 — 3 comments below

Eric Czarny — Dec 16, 04 38

I have had the hardest time settling on any specific variable naming convention, especially when it comes to data members. For myself, I just can't stand the standard naming convention used in Objective-C, the variables just become too long and unpleasant looking.

I break a very common rule, by adding an underscore to the beginning of private data members, but there really isn't any other alternative in my mind. I can't stand using prefix/underscore method, the variables just become ugly. Hopefully I'll settle on a better strategy soon. Any advice?

Scott Stevenson — Dec 16, 04 39

There's no question that Objective-C variables are longer than those seen in most ANSI C source, but the idea is that you're better off wasting some space than allowing things to be ambiguous.

Out of all the source code I've looked at, I've had more success with getting meaning at a glance from ObjC stuff than anything else. This is due in no small part to the naming conventions.

As for private ivars, the suggestion is that you do something like DC_elementName or DC_contentsHint, using the same prefix as the class itself. Part of the reason for this to avoid collisions with ivars declared in super classes such as NSObject, NSProxy, or perhaps some of the magical runtime subclasses.

Chris — Dec 16, 04 43

Hm. I tend to use the MacApp convention for ivar names (fElementName or fContentsHint). This is less ugly than most, and still differentiates an instance variable from a local, which I think is important.

Keep in mind also that Objective-C base class instance variables are fragile: you can't add new ones without breaking third-party clients. Methods, on the other hand, are not fragile. So I don't worry too much about the superclass ivars, but I do worry to some degree about method names.

Comments Feed

Comments Temporarily Disabled

I had to temporarily disable comments due to spam. I'll re-enable them soon.