Coding guidelines should specify what constructs can be used

Derek Jones from The Shape of Code

There is a widespread belief that an important component of creating reliable software includes specifying coding constructs that should not be used, i.e., coding guidelines. Given that the number of possible coding constructs is greater than the number of atoms in the universe, this approach is hopelessly impractical.

A more practical approach is to specify the small set of constructs that developers that can only be used. Want a for-loop, then pick one from the top-10 most frequently occurring looping constructs (found by measuring existing usage); the top-10 covers 70% of existing C usage, the top-5 55%.

Specifying the set of coding constructs that can be used, removes the need for developers to learn lots of stuff that hardly ever gets used, allowing them to focus on learning a basic set of techniques. A small set of constructs significantly simplifies the task of automatically checking code for problems; many of the problems currently encountered will not occur; many edge cases disappear.

Developer coding mistakes have two root causes:

  • what was written is not what was intended. A common example is the conditional in the if-statement: if (x = y), where the developer intended to write if (x == y). This kind of coding typo is the kind of construct flagged by static analysis tools as suspicious.

    People make mistakes, and developers will continue to make this kind of typographical mistake in whatever language is used,

  • what was written does not have the behavior that the developer believes it has, i.e., there is a fault in the developers understanding of the language semantics.

    Incorrect beliefs, about a language, can be reduced by reducing the amount of language knowledge developers need to remember.

Developer mistakes are also caused by misunderstandings of the requirements, but this is not language specific.

Why do people invest so much effort on guidelines specifying what constructs not to use (these discussions essentially have the form of literary criticism)? Reasons include:

  • providing a way for developers to be part of the conversation, through telling others about their personal experiences,
  • tool vendors want a regular revenue stream, and product updates flagging uses of even more constructs (that developers could misunderstand or might find confusing; something that could be claimed for any language construct) is a way of extracting more money from existing customers,
  • it avoids discussing the elephant in the room. Many developers see themselves as creative artists, and as such are entitled to write whatever they think necessary. Developers don’t seem to be affronted by the suggestion that their artistic pretensions and entitlements be curtailed, probably because they don’t take the idea seriously.

Emerging talent at the DevelopHER Awards 2018!

Paul Grenyer from Paul Grenyer


A couple of weeks ago I was honoured to be asked to judge and present the overall winner of the DevelopHER Awards 2018. There are a number of categories in the awards, including TechStar which I also judged, and the overall winner is chosen from the winners of the other categories.

I believe that the best developers start writing code at an early age and continue throughout their lives and on through their careers. As well as learning all they can, all the time, they give back to community around them and help other people develop as well.

Federica Freddi, who also won the Emerging Talent award, is clearly passionate about software development and is fully deserving of the DevelopHER award and I couldn’t have been more delighted to be able to present her with it on the night.

Federica told me "It is fantastic to see so many women recognised for their contribution to our industry. It is a huge honour for me to be able to represent so many talented people that are making the difference in tech. As an Emerging Talent, I still have a long way ahead and I don’t know what awaits for me in the future, however I am sure I will never forget to stop along the way to give back to people and help the next generations of tech stars to grow too."

I am hoping we’ll see Federica back in Norwich very soon.

I wrote a book

Frances Buontempo from BuontempoConsulting

I've written a book pulling together some of my previous talks showing how to code your way out of a paper bag using a variety of machine learning techniques and models, including genetic algorithms.
It's on pre-order at Amazon and you can download free excerpts from the publishers website.

The sales figures show I've sold over 1,000 copies already. I'm going through the copy edits at the moment. I can't wait to see the actual paper book.

Thank you to everyone at ACCU who helped and encouraged me while I wrote this.

I will be giving some talks at conferences and hopefully some meetups based on ideas in some of the chapters in 2019.

Watch this space.