Code style and patterns

NOTE HXA7241 2010-12-27T10:08Z

Code style is open to the same criticism as software patterns – they are indicative of a lack – but they may also be unavoidable

There is an argument that rejects patterns as valuable: patterns are said to be simply deficiencies in the programming language – if the language has the right features, patterns disappear.

Coding style looks very much the same. Recommended ‘good style’ of coding is truly just avoiding weakness in the form of the language. If the language had the right structure, ‘good style’ would be unnecessary. This applies at all levels, from brace alignment to what should go in classes and packages.

In fact, code style seems worse than patterns. Patterns are carefully structured and semi-formalised. They are like early prototypes of language structures. They have some determinate form. But code style seems to have a substantial core of whim and what looks ‘nice’. Much of it is actually not-programming – it does not properly belong in the subject of programming.

The very essence of communication is that something is agreed upon. If there are code ‘styles’, that means there are various choices for expressing the same structures. But this is the exact opposite of communication. It is a situation where we have not decided what we should do or what things mean.

(At least Python has one good example to follow. It took the way everyone indents – the way it makes sense to indent – and made it a rule of the language.)

If something is good and the right way to code – if there is an approved ‘style’ – make it a rule of the language. And if the language allows variation in a way of doing something, it should be there to express real logical structure. The aim should be a ‘style’-less language – the only ‘styles’ are the structures of the language.

But the defense of code styles could be the same as for patterns: styles are prototypical, potential forms. It is impossible to design a language ‘correctly’ in one go; it needs feedback from use (like any other kind of design). The implication is perhaps the need for better ways to iterate language design . . .

(But should we really have various fanciful, poetic ‘style guides’? – that is not programming, it is just a distraction.)

Sort-of related: