A question of style

February 13th, 2013

I’m a big fan of design principles for many reasons, not least of which is they way they can help to quickly resolve debates and arguments. They become a kind of higher authority to appeal to, taking opinion and ego out of the equation.

They can also lead to specific design patterns. This is something I’ve talked about in the past: the goals of a project inform its principles, which in turn inform the patterns that are used.

In the case of front-end design principles, they are informed by some higher-level goals. As I wrote on the Clearleft blog, some of those goals are user-centric, and some are developer-centric:

The user-centric goals include:

performance,

accessibility, and

device-agnosticism.

While the developer-centric goals include:

maintainability,

readability, and

modularity.

In turn, the final patterns produced—the actual markup and CSS and JavaScript—should be influenced by the resulting principles: the code should be maintainable, readable, and modular. So at the same time as we were figuring out high-level principles, we are also defining an in-house coding style.

Now here’s the thing about coding style: while it should ideally be informed by your design principles, there’s another factor that overrides everything else—what coding style is preferred by the developers who will be inheriting your code?

When it comes to things like tabs vs. spaces, or indentation, or naming variables, what matters is not which style you use, but that everyone is using the same style.

So, for example, I favour tabs over spaces. And I don’t tend to camelCase variable names in JavaScript. And I don’t like indenting my markup (I make judicious use of new lines instead). But I’m in the minority. I could try to force my style on everyone else at work but that wouldn’t be very productive. It’s far more important that everyone settles on the same style—any style—than it is for a coding style to be “correct.” The only “correct” coding style is the one that everyone is agreeing to use.

Mind you, people who write JavaScript functions with the opening curly brace on a new line are just plain wrong.