I usually try to avoid words like "clean" or "clear", even "understandable". Although there are books written about it, they are quite subjective.
Instead I speak about "explicitness", "expressiveness", "no surprises", etc.
I also try to keep a mental track of how much time I need to understand some code, for example from stack overflow, and i put that in a balance with writing a less smart code that requires less time to understand. And therefore less comments.
Interesting point of view. I kinda agree, and I like the words you use though they express mostly the same thing.
But I'd say that yes it is subjective, as almost anything in life. But many of the "clean" code guidelines are quite objective, like cyclomatic comlexity, separation of concerns, keeping functions and methods small, just to name a few. These have proben quite efective in reducing the complexity and increasign what you call "expressiveness" and also reducing surprises.
I'd also like to add my grain of salt to the comments thing. It might be controversial, but I hate comments in code (speaking of comments explaining a piece of code, public apis should always be commented and documented), they add an unnecesary layer of complexity and one that needs maintaing like other parts of the codebase. Code should be readable/understandable by itself, comments should not be needed (most times) to explain how the code works, the code should be expressive.
Every time you write a comment, you should grimace and feel the failure of your ability of expression. Robert C. Martin
Yes I totally agree with you on the comments! And that is totally my point: avoid comments with less smarter and more expressive code!
Its just that... Have you ever worked with a developer who will twist and bend the rules? Or just focus on 1 rule (usually code duplication)? Of course cyclomatic complexity is hard to bend, but out of the multiple rules in the Clean Code, a fair amount of devs I worked with knew just a few and applied them in a questionable way.
So I had to adapt :)
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 usually try to avoid words like "clean" or "clear", even "understandable". Although there are books written about it, they are quite subjective.
Instead I speak about "explicitness", "expressiveness", "no surprises", etc.
I also try to keep a mental track of how much time I need to understand some code, for example from stack overflow, and i put that in a balance with writing a less smart code that requires less time to understand. And therefore less comments.
Interesting point of view. I kinda agree, and I like the words you use though they express mostly the same thing.
But I'd say that yes it is subjective, as almost anything in life. But many of the "clean" code guidelines are quite objective, like cyclomatic comlexity, separation of concerns, keeping functions and methods small, just to name a few. These have proben quite efective in reducing the complexity and increasign what you call "expressiveness" and also reducing surprises.
I'd also like to add my grain of salt to the comments thing. It might be controversial, but I hate comments in code (speaking of comments explaining a piece of code, public apis should always be commented and documented), they add an unnecesary layer of complexity and one that needs maintaing like other parts of the codebase. Code should be readable/understandable by itself, comments should not be needed (most times) to explain how the code works, the code should be expressive.
Yes I totally agree with you on the comments! And that is totally my point: avoid comments with less smarter and more expressive code!
Its just that... Have you ever worked with a developer who will twist and bend the rules? Or just focus on 1 rule (usually code duplication)? Of course cyclomatic complexity is hard to bend, but out of the multiple rules in the Clean Code, a fair amount of devs I worked with knew just a few and applied them in a questionable way.
So I had to adapt :)