Yes, but readability is purely subjective. Different readers have different reading levels, some prefer poetry to prose, some have larger vocabularies etc.
Way too often, 'readability' is taken as making it understandable to the most junior developer. This is clearly a bad idea.
Yeah, agree. It is subjective. This is what makes it hard. Also, how do you convey context in the correct way so that when you look at the code later it still makes sense?
Therefor it's a good idea to spell out with your team what the expected base level of the audience is.
Depending on that, you can decide what patterns, libs, styles etc... can be used.
E.g. I expect our team to know/learn entry level functional programming concepts like functor and monoid. I accept that monad is too abstract for most, so only introduce it sparcely and have it documented clearly.
Not taking it for granted us greatly beneficial to avoid lenthy 'yes/no' pingpong games.
I'm a selftaught (web) developer. On sunny days, you can find me hiking through the Teutoburg Forest, on rainy days coding or with a good fiction novel in hand.
The Pyramid Principle employs argument contexts. Those feel a lot like function contexts or classes
'Write like you speak', 'Get to the point fast' and 'Be Brief' from the MS guide feel a lot like 'Write Readable Code For People' and the 'Single Responsibility Principle (SRP)' from Clean Code
SRP also reminds me a lot of the already mentioned, isolated argument contexts.
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.
Yes, but readability is purely subjective. Different readers have different reading levels, some prefer poetry to prose, some have larger vocabularies etc.
Way too often, 'readability' is taken as making it understandable to the most junior developer. This is clearly a bad idea.
Yeah, agree. It is subjective. This is what makes it hard. Also, how do you convey context in the correct way so that when you look at the code later it still makes sense?
The Clean Code book is a good read on this topic.
It is subjective.
Therefor it's a good idea to spell out with your team what the expected base level of the audience is.
Depending on that, you can decide what patterns, libs, styles etc... can be used.
E.g. I expect our team to know/learn entry level functional programming concepts like functor and monoid. I accept that monad is too abstract for most, so only introduce it sparcely and have it documented clearly.
Not taking it for granted us greatly beneficial to avoid lenthy 'yes/no' pingpong games.
I wouldn't really say it's purely subjective. There are traits to well-readable texts that code shares with posts or newspaper articles.
Studying guides like Microsoft Writing Guidelines, Clean Code and The Pyramid Principle of Writing helped me to take a lot of the subjectivity away. Even though these concepts come from somewhat different domains, they sound similar on many points: