I'm not rejecting them, merely pointing out that they're purely subjective. You didn't raise a single objective argument - 'not easy to see', 'very hard to understand', and 'hard to understand' couldn't be more subjective.
There are downsides to rigidly promoting readability and 'clean' code above everything else. I brought these up in a previous post:
You say it's subjective. But I cannot agree with this. This comes from my personal experience of teaching others, and reading code and I have 15 years of experience in that. But if you are not convinced with my experience - that is fine. It is possible to setup experiment that could confirm or deny the premise that I make. Experiment could look like so: we take 200 random developers. We split them in half. We present them with a piece of code. We ask them a comprehension question, that we ask to answer as fast as is possible. Alternatively we can ask a question to modify the code to do something slightly else - this also would test not only how easy it is to comprehend the code but also how easy it is to change it which is also important. We compare the results of 2 groups. And we have objective answer.
The answer will not be subjective. It will be objective result (time it takes to get to correct answer). I'm not asking a question "chose your favorite". I would be asking "what is result of the code" and I'll be measuring the time it takes to get to correct answer. Some developers are smarter than others but on average one group will prevail over the other. Naturally the code that is easier to understand will produce faster results. Alternative question can be set to modify code to do something else. Again we can measure time it takes for each group to get to modified code - the group that gets it faster is objective winner. And even better approach - that truly will make the biggest difference in two approaches - could be to throw in a subtle bug - and ask developer to find and fix the bug. While in case of comprehension developers may often make a confidence guess based on looks - when it comes to subtle bugs - you only get to fix them when you truly parsed and perfectly understood every comma in code.
Totally correct, the results of your poll would be objective - a mere accounting of the results.
However, none of this alters the fact that readability and understandability in themselves are subjective, which is the point you seem to take issue with.
It's not subjective. It has easily measurable effects. Easier to read code is faster to spot bugs, faster to fix bugs, faster to teach unfamiliar developer who's just starting their career. It starts from a discussion on what is hard to understand (the very points I mentioned). And if you don't agree with my complains then please throw a randomized trial and prove it to me that my problems are only in my head and that other people don't have the kind of issues that I encounter when reading your poorly written code.
Again, I never disagreed with you. I merely pointed out that the properties of readability and understandability are subjective, which - by definition - they are.
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'm not rejecting them, merely pointing out that they're purely subjective. You didn't raise a single objective argument - 'not easy to see', 'very hard to understand', and 'hard to understand' couldn't be more subjective.
There are downsides to rigidly promoting readability and 'clean' code above everything else. I brought these up in a previous post:
Preaching 'Clean Code' is Lowering the Quality of Developers
Jon Randy 🎖️ ・ Jun 25 '22 ・ 3 min read
You say it's subjective. But I cannot agree with this. This comes from my personal experience of teaching others, and reading code and I have 15 years of experience in that. But if you are not convinced with my experience - that is fine. It is possible to setup experiment that could confirm or deny the premise that I make. Experiment could look like so: we take 200 random developers. We split them in half. We present them with a piece of code. We ask them a comprehension question, that we ask to answer as fast as is possible. Alternatively we can ask a question to modify the code to do something slightly else - this also would test not only how easy it is to comprehend the code but also how easy it is to change it which is also important. We compare the results of 2 groups. And we have objective answer.
...based on the subjective opinions of 200 developers. The fact remains that readability and understandability are ultimately subjective.
My opinions are also drawn from long experience. I've been programming for 39 years, and doing it professionally for around 27.
The answer will not be subjective. It will be objective result (time it takes to get to correct answer). I'm not asking a question "chose your favorite". I would be asking "what is result of the code" and I'll be measuring the time it takes to get to correct answer. Some developers are smarter than others but on average one group will prevail over the other. Naturally the code that is easier to understand will produce faster results. Alternative question can be set to modify code to do something else. Again we can measure time it takes for each group to get to modified code - the group that gets it faster is objective winner. And even better approach - that truly will make the biggest difference in two approaches - could be to throw in a subtle bug - and ask developer to find and fix the bug. While in case of comprehension developers may often make a confidence guess based on looks - when it comes to subtle bugs - you only get to fix them when you truly parsed and perfectly understood every comma in code.
Totally correct, the results of your poll would be objective - a mere accounting of the results.
However, none of this alters the fact that readability and understandability in themselves are subjective, which is the point you seem to take issue with.
It's not subjective. It has easily measurable effects. Easier to read code is faster to spot bugs, faster to fix bugs, faster to teach unfamiliar developer who's just starting their career. It starts from a discussion on what is hard to understand (the very points I mentioned). And if you don't agree with my complains then please throw a randomized trial and prove it to me that my problems are only in my head and that other people don't have the kind of issues that I encounter when reading your poorly written code.
Again, I never disagreed with you. I merely pointed out that the properties of readability and understandability are subjective, which - by definition - they are.