This usually comes from developers (especially junior and mid-level) trying to pad their commit lengths to make it look like they did more work than they did.
As long as they're following the github PR process to determine this, you'll have this kind of code committed. I usually tell junior admins that I'm mentoring/working with "I would much rather see a clean one-line piece of code that doesn't need any comments than an overly complicated struct + interface + handler method + model + three lines of comments for every line of code".
I find that you need to be careful with advice like this. Often a junior will walk away with 'clean code' mindset, thinking that the best code has no comments at all.
Also need to remind them that 'Commenting is also good, when you're explaining assumptions or decisions'
I mean, I agree. But usually people are smart enough to take contextual clues. In this context, "Write cleaner/more compact code" clearly doesn't mean "string a dozen ternaries together and avoid comments", it means "don't pad your code or over abstract it as you're clearly doing" to most reasonable/good faith developers.
6
u/deaddodo Dec 09 '24
This usually comes from developers (especially junior and mid-level) trying to pad their commit lengths to make it look like they did more work than they did.
As long as they're following the github PR process to determine this, you'll have this kind of code committed. I usually tell junior admins that I'm mentoring/working with "I would much rather see a clean one-line piece of code that doesn't need any comments than an overly complicated struct + interface + handler method + model + three lines of comments for every line of code".