My Coding Style

Jul 29, 2011

My Code, My Rules.

This style guide is heavily influenced by the "Zarra Studios Coding Style Guide" [1], and whilst we agree on lots of things, there are major differences.

Spacing

Brackets

Naming conventions and locations

 Memory Management

 Method signatures

 File locations

 Booleans

Boolean can only have 2 values: YES and NO. True and false are incorrect.

 Comments

There is no such thing as too many comments. Comments are desirable but not required as the code should be self-explanatory.

 Avoid casting

This generally indicates you are probably doing something wrong and trying to lie to the compiler. Use id as the last resort.

 Libraries / submodules

Each library should contain a main .f file, named LibraryName.h, that includes all relevant headers of the classes defined/extended. It should also contain any settings, default values, etc.

 Debugging

 Golden Path

When coding with conditionals, the left hand margin of the code should be the "golden" or "happy" path. We should never see:

- (void)someMethod
{
  if ([someOther boolValue]) {
    //Do something important
  }
}

That is difficult to read. Instead the code should fail early and fail often:

- (void)someMethod
{
  if (![someOther boolValue]) return;
  //Do something important
}

Likewise, a method should not be bisected with a conditional as follows:

- (void)someMethod
{
  if ([someOther boolValue]) {
    //Do something important
  } else {
    //Do something else important
  }
}

This is also hard to read and should be re-written as:

- (void)someMethod
{
  if ([someOther boolValue]) {
    //Do something important
    return;
  }
  //Do something else important
}

There is one situation where a bisection of the code is acceptable:

- (void)someMethod
{
  if ([someOther boolValue]) {
    //Do something important
  } else {
    //Do something else important
  }
  //Do this no matter what
}

The goal here is to make the code on the left margin to be the "expected" code execution path and the code that is indented to be the exception. Consistency in this area is important to code readability.

 No Exception ;)

Throwing exceptions should be avoided - these are to be used for truly exceptional scenarios and not for controlling logic flow.

 Boyscout

Whenever you are in a piece of code it should be left cleaner than when you found it if possible. If you find code that violates this guide, correct it. If the code is out dated then update it.

 Version control

 Other things to consider

References:

This is a live document that is going to evolve over time. Feel free to get in touch with suggestions, etc. Thank you!

Web Analytics