As a developer I like to code in a certain style. Most developers have their own style and it works when you are working on your own project where there is no need to have input from or share the workload with other developers. When developers do need to share work or work as part of a team though, standards are needed.
Here at Wholegrain Digital, the leading London WordPress agency with a focus on purpose-led businesses and charities, we use coding standards as a core part of our workflow; rules that go beyond syntax and have a focus on style, layout, conventions and best practices when writing code. Almost all programming languages have standards in some shape or form; whether they are nicely documented or not is a different story (looking at you JavaScript).
Within all of our WordPress projects we mainly use 3 languages – CSS (SCSS), JavaScript, and PHP with HTML thrown in (for good luck). Each of these languages have their own standards:
- Idiomatic CSS which dictates the order of CSS properties to help make them easier to understand
- ESLint which supplies a style guide for writing JavaScript
- PSR-2 which is a style guide for writing PHP with a focus on interoperability (controversially not a WordPress standard)
We have these standards set up within our build tools for our internal starter framework, Granola, to ensure every WordPress project we undertake meets the exact same standards we have in place.
While we love them and follow them; some organisations and developers have their own standards but others simply cannot stand them. This post is about why to loathe them, why to love them – and why we use them.
Loathe them
If you have any experience with coding standards, you know how picky they can be with how things are done and you may even disagree with the standards, which makes them even harder to follow: whether it’s a specific rule that stops classes, functions and/or variables being in the same file or the order that CSS properties should be in. This can lead to slower uptake if they are implemented or they could be simply ignored by developers on the project.
There can also be a learning curve as you learn the standards yourself to make sure you are in the best place to be able to work on the project and move it forward without any issues.
Depending on your knowledge of the rules, working with coding standards can also slow your work pace down slightly as you get to grips with them and you spend time fixing any files that don’t follow the rules; this adds even more frustration when you are under pressure to get work done, meaning that the standards can go out of the window.
From my own perspective, when I first started getting to grips with these tools there was a learning curve as there is with everything else. After learning them I know I can go back to an old project and know my way around it very quickly and easily as it’s following these guidelines.
Yet, whilst there are reasons to loathe them, there are (in my opinion) better reasons to love them.
Love them
Having these standards makes us better developers: regardless of your coding style, having standards in place helps you learn things such as syntax errors and how to avoid them, as well as methodologies for file organisation.
Within the team at Wholegrain, we sometimes need to share projects – tight deadlines, holiday, sickness, size of the project, skill set are all reasons for this. Having coding standards in place makes it easier for any developer on the team to get up to speed with the project as they help make the code more readable and understandable.
By keeping all of our code consistent, it aids us in our problem solving where we start to think “how can I solve this” over “how can I code this” helping with both speed and stability.
These advantages are why we use them.
Why we use them
We use coding standards for five reasons:
- Communication
- Speed
- Sharing
- Stability
- Consistency
Since we’ve started to implement and work with these coding standards, we’ve also started to notice that we can’t tell who worked on a project once it’s out the door – the code looks like anybody in our team could have worked on it. By having and conforming to this “house style”, it means that the project will have more consistency and be open to any developer within the team.
The key thing that sticks in my mind with standards and coding style is that no matter how many people work on a project it should look like only one person built it – while coding standards can’t fix this on their own, they are a step in the right direction.
Why you should embrace coding standards?
If you are part of a team without coding standards or keep coming back to older code,whether a project you actively support or its a product you constantly build upon, coding standards are almost imperative.
Build tools like Gulp or Webpack can be easily extended to include these tests so you can continuously check your files on save, including running PHP CodeSniffer to run your PHP through its tests using the rules you have already set within your build tool directly or within a phpcs.xml file in your project.
You can read up on the different standards to find what works for you and your team (if you have one) and integrate them with your build tools.
You should always automate what you can so that you can concentrate on what really matters – which in this case is code quality to help you move forward with any project, whether sharing a project with another developer or not.
To sum up, strong coding standards within a development team make it far easier to collaborate on projects, deliver higher quality code and make websites easier to maintain in the long term. That’s good for the development team and the client!