Table of contents

The GDS Way and its content is intended for internal use by the GDS community.

Programming language style guides

This is a manual to accompany the programming language recommendations.

Code style guides

Developers read code much more often than they write it. These guidelines are intended to improve the readability of code and make it consistent across GDS projects.

A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important.

But most importantly: know when to be inconsistent – sometimes the style guide just doesn’t apply. When in doubt, use your best judgement. Look at other examples and decide what looks best. And don’t hesitate to ask!

Some good reasons to ignore a particular guideline:

  • When applying the guideline would make the code less readable, even for someone who is used to reading code that follows this style guide.
  • To be consistent with surrounding code that also breaks it (maybe for historic reasons) – although this is also an opportunity to clean up the existing code.
  • Because the code in question predates the introduction of the guideline and there is no other reason to be modifying that code.
  • When the code needs to remain compatible with older versions that don’t support the feature recommended by the style guide.

We’ve got a consistent style for:

Some of the guidelines in the style guides are codified in a .editorconfig file. Place a copy of this file in your project’s repository to have tooling that supports EditorConfig automatically adhere to the guidelines.

This page was last reviewed on 6 December 2018. It needs to be reviewed again on 6 June 2019 by the page owner #gds-way .
This page was set to be reviewed before 6 June 2019 by the page owner #gds-way. This might mean the content is out of date.