Hacker News Reader

Comment by ianbutler | Hacker News Reader

I don't think there's an objective assessment of good code. I've been writing code for over 20 years at this point and most times I've seen what people describe as their own good code I disagree with various decisions.

Experience CAN remove pitfalls, though developers even disagree about those sometimes.

Organization, chosen abstractions, naming etc are basically personal thinking and have differed on every team I've ever been on.

When it's been good is when it's been consistent and that's taken a strong personality the team trusted to have authority.

View on HN

Good code is subjective, especially once you start wandering into the territory of more esoteric approaches such as functional programming, domain-specific languages, code-generation, etc.

Bad code is one of those things that we can almost all agree on, often even the person writing it.

Alternatively: I don't know how to make a good movie, but I can recognise a really bad one, and you'll almost certainly agree with that opinion. You and I however will almost certainly not agree on what our favourite movie of all time is. The nuances and personal tastes become more important at the last few percentage points approaching 100% "like".

I think we can agree on a version of bad code, specifically extremely bad code.

Just as we might agree on universally panned bad movies, but disagree on cult followings or one of us for a particular reason can't stand a popular movie.

That is to say we can all agree on extremes, but just because something isn't extremely bad doesn't make it good in everyone's eyes and that's where the contention is.

Yep, you beat me to it. Arguing over good code is pointless. We should instead agree on various metrics on what a bad code is and try to avoid those.

I used to obsess about code, but over time I came to dread coming into a new codebase and finding layers upon layers of pointless mini-architecture. There would be a controller calling into a separate package where the actual implementation is, then that would call into a layer where service calls are, then all that would be abstracted just in case and built into a separate jar, and so on. And there would still be cross-dependencies. I think what happens there is a kind of purity spiral effect and developers have to go through the motions of following the best practices du jour instead of just calling the damn method.

I feel like its just a reflection of people's minds. People organize their thoughts very different from one another and people often don't organize their thoughts at all when under certain constraints such as needing to ship NOW.

Especially with enterprise code you're hammering your thoughts into a shape roughly compatible with someone else's so its no wonder overtime with the constant revolving door of people that without careful shaping things can get nuts.

Reply on news.ycombinator.com