> So the rules can be codified sufficiently to test people on, but they can't be codified for a computer? Small note: readability isn't a test or quiz you take

> So the rules can be codified sufficiently to test people on, but they can't be codified for a computer? Small note: readability isn't a test or quiz you take (asterisk). It's obtained by merging code in the language you want readability for. If you merge code for a language often and the reviewers have very few style-based questions for the code then you will get readability fairly quickly. > The only one that sounds more difficult to codify is telling people of the existence of duplicate functions. But as someone who contributes to the linux kernel, I can tell you right now that the only way that works reliably is to have a very large pool of reviewers. Very experienced engineers frequently miss what people are doing in other parts of the source base, the name might not be what they expect, etc, etc, etc. A better example would be knowing when you should use `const std::string&`, `std::string_view` or `char*`. Example: https://abseil.io/tips/1 https://abseil.io/tips/1 The best readability advice I have recieved has been: 1. Direct "I was confused by X" or "The recommended way to do A is using B", etc 2. Reasoned: "std::string_view is more efficient and clearer in intention than char ptr, it also improves type safety as it is read only and clear about ownership" 3. Linked to source material where examples are given totw or other examples in the code.