Coding Standards

If you’re working for Camel Punch as a contractor or collaborator, this page is for you. You might also like this page if you’re interested in how others feel about programming and markup style.

Why we set these standards

Just as a newspaper prescribes stylistic guidelines for articles, at Camel Punch we prescribe a certain style for our code. It’s important that developers are on the same page when collaborating. Arguably, it becomes more important to communicate intent within code when developers are geographically separate. At Camel Punch we like developer freedom, and we work regularly with sub-contracted specialist designers and developers. It’s therefore really important to keep style as consistent as possible.

But my style is better!

Many developers see coding standards as an affront to their freedom of personal expression. Unfortunately, it’s often the case that personal quirks in coding style cause bugs and misunderstandings within teams. We don’t have much sympathy for personal preference unless it’s considered a more readable or easier-to-understand version of an existing standard, in which case the style in question should become a standard.

When efficiency trumps readability

Occasionally, it will be worth using less readable code to improve run-time efficiency. This is an exception to the rule. When efficiency really does trump readability, code comments are essential.