I actually started work on one after a meeting we had with a few developers and project managers back in October 2010 but I kept getting interrupted. I kept getting taken off ‘just writing documentation’ and put on other projects because they were seen as more important.
The importance of code conventions
There are a few things that go along with that: […] When you look at the code it’s laid out nicely; you’re playing by the rules that have been set down at your company or on your team.
One of the biggest things that annoyed me in my career is that you go some place and you’d have five people on the team and they are all writing code slightly different. How many times have you ever opened up a file and before you did anything you’ve reset all of the formatting?
The discussion then moves on to the importance of code formatting issues. One of the co-hosts confesses that he has often become more incensed by co-workers using inconsistent formatting than by anything else because it adds needless extra mental effort.
Zakas agrees and refers to the work of Daniel Kahneman’s book Thinking, Fast and Slow explaining that our brains get used to particular patterns, and when you detect an anomaly in that patterns that you’re used to you switch into a different mode in your brain and that upsets you.
Zakas explains that when he worked as a consultant he used to go into companies to help them sort out their coding conventions:
I’m a very big believer in the broken windows theory where you need to do the small things right if you have any chance to get the big things right.
Jonathan Snook: SMACSS
One approach to organising CSS code that I’ve been investigating and trying out is SMACSS (scalable and modular architecture for CSS) which has been developed by Canadian developer Jonathan Snook.
In his book he talks about structuring your CSS not only in terms of how to organise the code but also the naming convention that he uses for classes and IDs.
What I’ve found immediately helpful, however, is the way that he categorises CSS rules into five groups:
These are the defaults, usually single element selectors such as a, input or li.
These rules divide the page into sections.
These rules introduce reusable blocks, such as sidebar sections, product lists, carousels, tabs.
This was a new way of thinking for me, which I find particularly useful: how do things look in a particular state, e.g. when something is hidden or expanded, active or inactive. I especially like his class naming conventions for state which makes them readable, for example: .is-pressed, .is-disabled.
Themes are something that we use already on the University website: we often have a common core of page styles and elements but which are themed or skinned differently, for example compare Current Staff with Current Students.
I’ve used this approach in a few stylesheets now and the clarity it brings to organising my code has been very welcome. I’ve found myself asking “what is this to do with?” This is layout so the code needs to go in this section, that is a module so it needs to go into this other section. It has allowed me to offer a generic theme within the module itself, and over-rule it with a particular theme, if required. Very useful.
My next task is to explore Snook’s naming rules (he uses prefixes such as l- for layouts, is- for states) and compare it against the BEM (block-element-modifier) approach advocated by Yandex.
No doubt I will report back.