Written by Brightec Team
Aug 22, 2014

Code Style Guide

There’s nothing worse than someone else’s code.

Cracking the code

There’s nothing worse than someone else’s code. Well, actually there are plenty of things worse than that. However, when you’ve got your head down on a job, the last thing you need is the stress of trying to crack the code created by a well intentioned developer operating on a slightly different wavelength to you.

Coding in a team

When you're working within a team of developers, it’s important that everyone structures and formats the code in the same way. This saves time, reduces errors and hopefully alleviates frustration (well, at least some of it).

Many development agencies will unwittingly develop a common code language and set of practices but often these are not documented.

In the fast moving world of app development, often working with growing and evolving teams of developers, documenting your code style & practices by creating a 'code style guide' is essential.

"documenting your code style & practices by creating a 'code style guide' is essential"

What is a 'Code Style Guide'?

Quite simply, a code style guide is a set of rules and guidelines used when writing computer software. 

The guide generally lists the rules for how to name variables, how many spaces between blocks of code, best practices and more.

More information on code style can be found here: http://en.wikipedia.org/wiki/Programming_style

Our guide

We’ve recently grown our team at Brightec and have multiple developers working on the same codebase so now seemed a good time to formally introduce our own style guide. 

We used the excellent style guide from Ray Wenderlich available here: https://github.com/raywenderlich/objective-c-style-guide as a starting point. 

raywenderlich.com is an amazing resource for weekly tutorials on all aspects of app development and has hundreds of leading developers contributing. We knew that the Ray Wenderlich style guide would be a well crafted and thorough reference for us to base our own style guide on.

So we forked the style guide on Github and amended it to reflect our own style. As it turned out, it did not require too many amendments. We already formatted our code in mostly the same way, nevertheless there were a few things that we amended, added and removed.

You can see our style guide here:


Feel free to fork it if you want to. We're pleased with it and we’ve sent it out to all the team here at Brightec. We’re also working on an Java version for Android development buts it’s not quite ready yet, we’ll post it here once it’s complete.

This article was originally written for Brightec by Cameron Cooke