I think you forgot to mention important point when it comes to DRY: Dependency. The more code is reused at different places the more dependency you create. This is especially an issue when it comes to refactoring pieces of code into a library. Then you need to maintain your lib, update other services that use that lib, even maintaining multiple versions. So DRY across service boundaries is mostly not a good thing.
A second aspect is
You must comment your abstractions
I am personally a big fan of clean code and this would be a violation to the principles. If you want to add comment, you should refactor or rename the code in a proper manner that reflects what you wanted to comment. If it’s hard find a proper name, then the code probably does too much and violates other principles. If the abstraction is too complex too understand, it probably need to be removed.
"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 think you forgot to mention important point when it comes to DRY: Dependency. The more code is reused at different places the more dependency you create. This is especially an issue when it comes to refactoring pieces of code into a library. Then you need to maintain your lib, update other services that use that lib, even maintaining multiple versions. So DRY across service boundaries is mostly not a good thing.
A second aspect is
I am personally a big fan of clean code and this would be a violation to the principles. If you want to add comment, you should refactor or rename the code in a proper manner that reflects what you wanted to comment. If it’s hard find a proper name, then the code probably does too much and violates other principles. If the abstraction is too complex too understand, it probably need to be removed.
"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.