"I am personally a big fan of clean code and this would be a violation to the principles."
Be wary of dogma. Principles are important in that they help provide a common understanding across a team, but principles are, by definition, high-level --
the reality is that not everyone will agree on what constitutes proper naming or when code does too much. The occasional code comment can go a long way to provide clarity, particularly when there's some unobvious business reason for what might look like strange logic or naming.
I agree, naming is hard. But it’s usually worth it. In my team, we only do comments for ugly workarounds with a link to an issue tracker to check if the causing problem has been resolved. Everything else has proper method names. We do that for years now and it’s working great for us. Once in a while, I have to look at other team’s code and find a lot of abandondoned comments that stating misleading or even wrong things in contrast to what the code actually does.
And yes, principles can be ignored in certain situations, but I found almost all clean code principles very helpful worth following.
I thinks the saying is „you have know the rules to break them“...
If naming a method is too difficult, it is likely doing too much. IsObjectEmpty() is pretty clear. GetProducts() is pretty clear. GetReviews() and they should be doing exactly what its name states. Reading these comments makes me wonder if any of these people have a CS degree.
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 am personally a big fan of clean code and this would be a violation to the principles."
Be wary of dogma. Principles are important in that they help provide a common understanding across a team, but principles are, by definition, high-level --
the reality is that not everyone will agree on what constitutes proper naming or when code does too much. The occasional code comment can go a long way to provide clarity, particularly when there's some unobvious business reason for what might look like strange logic or naming.
I agree, naming is hard. But it’s usually worth it. In my team, we only do comments for ugly workarounds with a link to an issue tracker to check if the causing problem has been resolved. Everything else has proper method names. We do that for years now and it’s working great for us. Once in a while, I have to look at other team’s code and find a lot of abandondoned comments that stating misleading or even wrong things in contrast to what the code actually does.
And yes, principles can be ignored in certain situations, but I found almost all clean code principles very helpful worth following.
I thinks the saying is „you have know the rules to break them“...
If naming a method is too difficult, it is likely doing too much. IsObjectEmpty() is pretty clear. GetProducts() is pretty clear. GetReviews() and they should be doing exactly what its name states. Reading these comments makes me wonder if any of these people have a CS degree.