Much of practice here can be summarised as: Code should read so that the intent of the programmer is clear. Omit types where they arent relevant to understandi

Much of practice here can be summarised as: Code should read so that the intent of the programmer is clear. Omit types where they arent relevant to understanding the code, include them where they are. Good code, then, only arises from good programmers who understand relevance and communication with code. General prescriptions are no use. There is no correct whitespacing, no correct phrasing, no correct chunking, (and so on). There is only whether you have written code for the audience who will read it. I suspect much of practice around software eng. here could be improved by peer challenges around program composition.