What is the Objective-C coding style?

The first thing I do when I add any third-party code to my application is to reformat it according to my personal coding preference:

// Single line comments only

// I never put spaces inside my parenthesis 
-(void)myOCDMethod
{    
    // If an if or for statement has only one instruction, I don't use brackets
    if(this)
        [self that];
    else
        [self somethingElse];

    // If I do have to use brackets, they go on their own lines so that they line up
    if(this)
    {
        [self that];
        [self andThat];
    }

    // I always put the pointer asterisk next to the instance name
    NSObject *variable = [[NSObject alloc] init];

    // I always put spaces around operators
    if(i == 0)
        x = 2;

}

      

What OCD encoding format are you using?

+1


source to share


5 answers


I do a lot with a few differences:

I always insert spaces before and after parens: -(void)myOCDMethod -> - (void) myOCDMethod

I leave the curly braces on one line:

if (this) 
{
  //code
}

      



becomes
if (this) {
  //code
}

      

If I feel especially OCD, I line up my locals:


float                l1;
NSArray              *array;
ReallyLongClassName  *object;

      

Finally, TABS, not SPACES.

+3


source


Tabs are evil in the middle of the line and space is rock! Example:

int    n;
double d;

      

Let the tab size be 4. I'll indicate them with dots:

.   .   .
int     n;  // two tabs here
double  d;  // one tab here

      



If this code is opened on another developer machine where the tab size is 2, he will see the following image:

. . . . .
int   n;
double  d;

      

So, you have to use the same tab size (and that won't work, since your code can be reused by anyone in the world - you can't force everyone) or stick to spaces. Got it?

+2


source


Pretty much the same as yours, although I leave a space between "-" or "+" and the return type opening parenthesis. Oh, and am I using (condition)? (value1): (value2) thing a lot, mostly for assignments and math ... I know it makes the code harder to read, but it saves three lines.

+1


source


  • Mark the code correctly
  • Correct line breaks. (Max one line break; line break before each function and comment, etc.)
  • Correct naming conventions
0


source


I am on

NSString*  aString;

      

but not

NSString  *aString;

      

(For both variables and arguments)

The rationale is that in the first case it looks like "aString is an NSString pointer", while the latter reads more like "(dereferenced) * aString is an NSString object". Especially in Obj-C, where all objects are heap allocated and therefore denoted by pointers, the former is less confusing.

I only align curly braces for function definitions, metos definitions and ivar blocks because they are first level scopes in the file (something outside globally) and feels "leaking" otherwise. Aligned, the block is more visible, without "holes".

In method signatures, I use this spacing:

- (void) methodName:(Class*) object;

      

I like to vertically align colons when there are more than two arguments (unless the first param tag is much longer than the method name when it breaks). Xcode nicely auto-tabs to this.

Everything else is similar to you.

0


source







All Articles