As organisations which deliver software grow, there’s a very common need to define what they see as best practice for software development.
This serves many purposes including helping new starters and prospective developers understand how they work and providing a framework to help resolve any disagreements about syntax or style.
In many organisations this best practice is defined as a set of coding standards or a style guide. These are often detailed rules specific to one programming language - for instance, here’s an example from a Ruby style guide:
“Use I18n.t 'dot.separated.key' over I18n.t :key, :scope => [:dot, :separated]”
While this kind of guide has its place, and consistency in a codebase is an admirable aim, many of these formatting standards can be automated with modern development tools (an approach known as ‘linting’).
We prefer to state the aim - ‘be consistent’ - rather than listing every conceivable implication of it.
Don’t get me wrong - coding standards are a perfectly valid attempt to distill years of experience into a set of do’s and don’ts. But here we believe there are several drawbacks to this approach. Coding standards tend to be:
Decisions made for you, by someone else
You may not agree with the standards on particular points in particular circumstances, you just have to accept them - this can lead to frustration and lack of trust in the standards.
Too detailed and specific
For example, Google’s C++ coding standards are 81 pages long, just for one programming language. Documents this long take a huge amount of time to write, check, and read - time that we believe could be better spent on delivery.
Off-putting to juniors
The focus is on being prescriptive rather than helping people to learn. Less experienced developers will simply repeat what the standards say without necessarily understanding the reasoning behind them.
So at MoJ Digital & Technology, we’ve taken a different approach. We’ve tried to distill our learning and guidance into a set of 10 simple, memorable principles to guide developers in their decision-making.
Individual product teams are free to choose the particular formatting rules that they’re happy with, and are encouraged to automate the process of applying them.
We believe a sound set of principles should:
- Empower people to make good decisions for themselves.
- Be comprehensible even to non-technical people
- Help people to learn through applying the principles to their own work
- Be concise and memorable easy to print out and stick to the wall, easy to refer back to
- Be generally applicable to similar types of development, whatever the language
- Provide a framework for discussions rather than a long list of hard and fast rules
So here they are - the MoJ Digital Development Principles, complete with explanatory notes and some language-specific details. Please feel free to use or adapt these principles for your own teams.
If you have any questions or feedback, we’d love to hear them. Let us know in the comments below or by tweeting @Justice_Digital.
2 comments
Comment by David H. Deans posted on
MoJ Digital and Technology is wise to follow an open and collaborative path to agile development. Many of the principles that you list are the same basic guidelines adopted by the greater open source software community. The Linux Foundation is a resource for additional insights on this topic.
Comment by Al Davidson posted on
Hi David, thanks for your comment! We're very aware of the open-source philosophy, and all new code in our digital services is coded-in-the-open by default. Broader agreement on how to do things well can only be a good thing