In my opinion the only way to control subjective factors of readability is with code reviews e.g. if every team member can read and understand give code.
I agree, your team could be filled with geniuses that write 1 liners that are "non-trivial and elegant". Or you team could be filled with random people with minimal code experience.
Slap on as many metrics as you want, it will just give you a number that ultimately means nothing.
I'd grab the "weakest programmer" and ask them to review some given code for readability. Worst case they learn something, best case the code should become more readable if it isn't simple.
The best kind of code should be easy to read even for a "beginner", but what a beginner depends on the company, culture and use case. :)
This approach kind of stops conversation. My idea is to understand what contributes to code readability, not to make it as ultimate measure (I mentioned Goodhart’s law).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree, your team could be filled with geniuses that write 1 liners that are "non-trivial and elegant". Or you team could be filled with random people with minimal code experience.
Slap on as many metrics as you want, it will just give you a number that ultimately means nothing.
I'd grab the "weakest programmer" and ask them to review some given code for readability. Worst case they learn something, best case the code should become more readable if it isn't simple.
The best kind of code should be easy to read even for a "beginner", but what a beginner depends on the company, culture and use case. :)
This approach kind of stops conversation. My idea is to understand what contributes to code readability, not to make it as ultimate measure (I mentioned Goodhart’s law).