21st July 2014

Are Style Guides a Developer’s Best Friend?

Scroll down

styleguides

Deadlines rule the roost over the lives of developers. So naturally we’re always looking for ways to increase our chances of meeting those deadlines. And one of the best ways to do this is through the use of a style guide. In the world of design and development, style guides can come in two forms: typically on a project level, you have a style guide where you define the styles of a project, such as buttons, heading and link styles etc. And the second, more commonly on a team level, you have a style guide which is essentially used to define how you build and code that project.

In teams of developers, it’s vital that everyone is on the same page when it comes to building projects. If Developer A builds a project one way, then Developer B, who does things differently, has to take over, there will inevitably be time spent for Developer B to work out how Developer A has done things. Obviously, this is wasted time, so there needs to be some way of reducing or removing this wasted time from projects.

This is where the latter of the aforementioned style guides comes in. In it’s simplest form, this style guide defines a set of rules for how the developers should build the organisation’s projects. These can be simple rules, such as whether to use spaces or tabs for indenting and how to structure the files within or, perhaps, it could say what techniques a developer should use in certain situations. It can be as narrow or as broad as a team needs it to be.

There’s no right or wrong answer for what a style guide should contain. Different teams can have different requirements. But the bottom line is that a style guide is there to create consistency between projects. So the rules it contains must be adhered to, otherwise it may as well not exist.

Here at Creode we’re using a growing style guide and adapting it to new technologies and techniques being introduced into our build process. Right now, it’s defining how our code should be written and our projects structured. This will no doubt grow further and will become invaluable as new members join our development team.

We’d love to hear from you if you or your team use a style guide. What does it contain? What benefits does it bring you? Let us know in the comments.