Hacker News Reader

Comment by jonahx | Hacker News Reader

> The problem with this code isn’t that it’s “ugly”. We’re not talking about aesthetics. The problem is that if there is a bug in this code, I don’t know where to start looking.

But this is precisely what people mean when they say it's ugly.

"Ugly" is what this gets translated as by your limbic system which registers in an instant: "fuck this big mess and the work it's going to be to reason about."

Aesthetics and usability are deeply entangled here, and the problem with that code is absolutely an aesthetic one. I want to say, more so. Because I experience it that way first, and only later do I enumerate the measurable reasons it's likely to be more buggy because of it.

View on HN

Ugly, given that it is an emotional word, applies to any code that you don't like.

WHY do you not like some code? To avoid pointless discussions about taste and gut feelings, I'd bring it down to falsifiable statements.

"This is hard to maintain, for reasons X and Y" is such a statement. As is: "This is hard to test for reason: It needlessly engages in combinatorial explosion" is another.

Yes, you could shorten that to 'ugly'. Good for you.

Nevertheless, I've seen tons of discussions referring to 'ugly' code where the reasons were solid but completely different from maintainability (for example: "It is longer than needed", "It does is not idiomatic for this language"), or even not particularly solid ("It is ugly because it isn't functional", "It is ugly because the style guide says all APIs should always be interfaces", "It is ugly because I see tabs, not spaces").

In a sense those are all finer grained extensions of the same concept: How hard it is to reason about the code. On the highest level are easily quantifiable things like wrapping several error producing segments in a single try / catch block, obscuring the source of an error. Use of interfaces makes documentation and refactoring easy. Then the lowest level stuff is pure style -- much more subjective, but meaningful in a team environment. When people write code in the same style, you spend less time parsing style differences and more times parsing the actual semantics.

It’s true that gut reactions _are_ in part based on analysis like this. But just like with machine learning you’re gonna have some false positives for unfamiliar APIs. Things might look “weird” superficially but actually not be a problem. Or it could look “clean” but have a bad Bug-O. Thinking about it in rational terms first can help.

I agree. To be clear, I wasn't arguing against the need for dispassionate analysis. Or arguing that emotional responses can always be trusted. I was arguing only against the claim that these two things are mutually exclusive.

> Or it could look “clean” but have a bad Bug-O.

I think this is possible but in practice rare. I'd be curious to see an example of code you think falls into this bucket.

the problem is that "ugly" isn't precise and can get translated from other reactions that aren't based on experience but are instead just cargo cutting. it's great to use the faster parts of our brains to reason but still important to make sure we're not accepting the mistakes they might make.

It's also an emotive word that can make discussion more heated. If you're reviewing somebody's code and you call it "ugly", they're liable to get upset, and it's too imprecise for them to act on. It's far more helpful and less combative to explain, in concrete terms, what you think its problems are, and how a different approach could solve them.

It's aesthetics because your brain can see it turns into a multidimensional graph with all sorts of cycles that's, for all intents and purposes, infinite.

Reply on news.ycombinator.com