When it comes to how to write code we're essentially faced with a usability problem. When we write an API function we want other people to use it. When we writ

When it comes to how to write code we're essentially faced with a usability problem. When we write an API function we want other people to use it. When we write internal functions we want other developers to use it. When we write programs we want some customer to use it. A lot of usability design has been somewhat formalized. We describe design in terms of signifiers, affordances, constraints, mappings and feedback. A lot the bad and best practices can be rephrased in these terms. If your program is "stringly" typed it's unclear which affordances your functions offer, that's bad. In OOP a lot is hidden from the user, if this is well done, you have constraints that keep you from doing something wrong, if it's badly done you have big objects with some state that's unobservable (lack of signifiers) so you can't understand what it does (lack of affordances). In FP you do this through function signatures, purity and strong typing. The type signature together with the function name can show you the affordances of the function. By constraining inputs and making outputs explicit (e.g. result types) you provide constraints and signifiers about their usage. A mapping is what we expect, e.g. from a knob. If you find 4 knobs and 4 hot plates on a stove, you instinctively know what they do. If the hot plates are somewhat shifted laterally against each other it becomes even easier to identify which knob is for each plate. In programming this could be the name of a function. A function called printX() shouldn't do anything except printing, otherwise it breaks the instinctive mapping that you expect. A function named isX() shouldn't return void. It should return a boolean. Of course you can't condense this down to a simple number, but at least you can describe why something is good or bad. The groundwork has been laid already.