DEV Community

Discussion on: Clean code, dirty code, human code

Collapse
 
d_ir profile image
Daniel Irvine 🏳️‍🌈

I don’t disagree. I used to feel this way. It’s just that at some point I realised that at this low level of line-by-line scrutiny it doesn’t really matter. A more important axis is time. Does the codebase improve over time? Does their coding style ‘improve’ over time? I say improve in quotes because what I really mean is does their style become more like my subjective idea of style over time?

I’d rather teach people to code like me by showing them my code than by spending time/energy poking holes in theirs.

Collapse
 
sinapis profile image
sinapis

I get your point, and I agree about style - Style is a matter of personal preference. There are also different "schools of thought" each with their own, respectable, set of principles. We should not fight a war to "convert" people with other principles to hold our own.

But there exist code that is objectively bad. It's not a matter of style, it's not a matter of different principles, it's a matter of lack of principles.

When code cannot be read by human beings, when it misleads and hides the developer intent, it's an objectively hard code to maintain. When code contain wrong abstractions, when it is littered with unnecessary code duplication, when it contains huge spaghetti methods, when it is riddled with hidden dependencies, when it is so brittle that touching some part breaks some distant completely irrelevant other part... It's just plain dirty code, filled with bad practices.

Just like there are good principles, there are also bad practices.

And we should not be afraid to say it.

Thread Thread
 
daniel13rady profile image
Daniel Brady

But there exist code that is objectively bad....When code cannot be read by human beings, when it misleads and hides the developer intent, it's an objectively hard code to maintain....And we should not be afraid to say it.

@sinapis I agree 💯 We should not be afraid to criticize unmaintainable work, and if you can't fix it, I shouldn't ship it.

But not all 'objectively bad' code is worth my time to criticize. It's taken me a while to come to this perspective, and I still routinely lose it (and truthfully, sometimes I willfully forget it). Giving criticism is challenging to do well, because the goal of criticism isn't to improve the current iteration: that's impossible, it already happened. Your goal with criticism is always to improve the next iteration, and the next and the next; focusing too tightly on the code can limit the usability of your feedback, but focusing too broadly on design principles isn't likely to stick in anyone's head for long.

Additionally, iterations and feedback are happening in the larger context of a team's current sprint of work. Your personal priority may be to help your team produce elegant, quality code; but your real priority is working together to produce the best quality you can within your given constraints. Sometimes the pull request has also gone through 4 iterations already and the sprint is nearly over and Sales needs you to do that thing and so you say let's just get this to a 'save point' so we can continue iterating when we're back in town next month.