Programming standards: I have read many different rules a programmer should apply when writing code. You can find many such checklists on the Internet, some/most dedicated to a specific company or a specific programming language. My rules of choice started like that, but I think that the best rules are less specific, and more of a strategic nature.
I own two books that I regard quite highly, in this context. For Pascal, there was (is!) the essential book “Pascal with Style: Programming Proverbs” – the title makes it look specific but it really isn’t (quite a feat for a book from 1979). Alan Davis compiled the excellent “201 Principles of Software Development“. In fact, some of his principles apply first and foremost to IT management – principle 29 has a nice passage:
In general, when anybody finds an error in a software engineer’s product, that engineer should be thankful, not defensive. To err is human. To accept, divine! When an engineering error is found, the person causing it should broadcast it, not hide it. The broadcasting has two effects: (1) it helps other engineers avoid the same error, and (2) it sets the stage for future nondefensive error repair.
The “standards” spectrum also includes the always funny “How To Write Unmaintainable Code“, a page I have mentioned several times already on this blog. If you can’t stand the humour and the anti-examples, you’re not a good developer!
But when lives may depend on the quality of the code, less rules surely is better, if only because they are easier to remember. So here they are, short and powerful: “NASA’s 10 rules for developing safety-critical code“.
Holzmann believed that complying with NASA’s rules, strict as they might be, can lessen the burden on developers and lead to better code clarity, analyzability and safety.