For me, clean code means knowing and applying established coding and design principles like "single responsibility", "program against interfaces", "composition over inheritance" , "comment why, not how" "apply formatting", "write unit tests", "avoid global mutable state", etc. I don't think they are "just opinions", but a result from long real-world experience building maintainable software. There are good reasons why such principles exist. Of course they're not "truths" either, but every developer should know why they exist so they can weigh whether to follow them or make an exception.
I don't think they're just opinions, though some could be interpreted as such. Over time I have seen many beginers and younger folks misinterpret the meaning of it, or even more advanced developers writing posts that just scrap the surface and make people think that's all there is too it. The main point I wanted to get across (though I might have failed) is that it's not something that is done immediately or just by using the principles. As you said one must understand why they are used, when to use them and be consistent thoughout the life of the codebase. It takes time, discipline and knowledge.
Thanks for explaining! I've also seen some posts here titled such as "Don't use else-if", such opinion pieces are easily confused with deeper principles that I think of as "clean code". Thanks for your good and thoughtful post!
Google's code review guide says this about design:
"Aspects of software design are almost never a pure style issue or just a personal preference. They are based on underlying principles and should be weighed on those principles, not simply by personal opinion. Sometimes there are a few valid options. If the author can demonstrate (either through data or based on solid engineering principles) that several approaches are equally valid, then the reviewer should accept the preference of the author. Otherwise the choice is dictated by standard principles of software design."
I think many of the "clean code" principles are such standard practices and not highly opinionated.
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.
For me, clean code means knowing and applying established coding and design principles like "single responsibility", "program against interfaces", "composition over inheritance" , "comment why, not how" "apply formatting", "write unit tests", "avoid global mutable state", etc. I don't think they are "just opinions", but a result from long real-world experience building maintainable software. There are good reasons why such principles exist. Of course they're not "truths" either, but every developer should know why they exist so they can weigh whether to follow them or make an exception.
Thanks for your take, I agree with you.
I don't think they're just opinions, though some could be interpreted as such. Over time I have seen many beginers and younger folks misinterpret the meaning of it, or even more advanced developers writing posts that just scrap the surface and make people think that's all there is too it. The main point I wanted to get across (though I might have failed) is that it's not something that is done immediately or just by using the principles. As you said one must understand why they are used, when to use them and be consistent thoughout the life of the codebase. It takes time, discipline and knowledge.
Thanks for explaining! I've also seen some posts here titled such as "Don't use else-if", such opinion pieces are easily confused with deeper principles that I think of as "clean code". Thanks for your good and thoughtful post!
No worries, glad you liked it! And thanks for your addition.
Yup, those types of posts kinda inspired me to write this post!!
Google's code review guide says this about design:
"Aspects of software design are almost never a pure style issue or just a personal preference. They are based on underlying principles and should be weighed on those principles, not simply by personal opinion. Sometimes there are a few valid options. If the author can demonstrate (either through data or based on solid engineering principles) that several approaches are equally valid, then the reviewer should accept the preference of the author. Otherwise the choice is dictated by standard principles of software design."
I think many of the "clean code" principles are such standard practices and not highly opinionated.