Hacker News Reader

Comment by anononaut | Hacker News Reader

I agree with you to some degree, but it needs to be said that _good_ code is very expressive. It should reveal the developer's intent clearly. "Doing a thing" is fine for amateurs or a quick script, but for large enterprise application development, it doesn't go nearly far enough. Good names, good function arrangement, plus everything else we should be studying needs to be applied well. If done well, it certainly should not take a half hour presentation to present a dozen lines of code. That tells me that the code is too complicated, too dense, too many levels of abstraction together, too much I have to keep in mind to understand some main idea. Very dense code is, more often than not, bad code.

I don't think reading codebases is an exercise worth doing often, but all the same good code should read like well written prose. It's difficult to appreciate that if an individual hasn't poked through a number of codebases of varying quality.

View on HN

I think the problem with this assertion is that over time "good" code often ends up littered with important conditionals to handle cases that upset the general readability and expressiveness of the initial delivery. Imagine a FinTech working on some kind of trading platform. It seems simple and clear at first, but over time more and more safety mechanisms, edge cases, regulatory obligations, and all kinds of other things need to be added -- and often they need to be added _now_, which means that readability is not the primary concern. I think that's the point of the article; readability is often not the most important thing.

I don't think that suddenly catapults the code into "bad" code, and in fact it's this kind of accumulated wisdom that makes full rewrites so famously expensive. The initial core of the idea might be able to be expressed in a simple and beautiful way, but over time it turns out that almost nothing is truly simple, and complexity accumulates. But it's good complexity, it's important to the business, and it doesn't mean that it's bad code.

Complexity and quality can be completely orthogonal. When they aren't, complexity and quality of code are proportional, which is a smell. Readability is often cited in lists of what makes good code, and rightfully so, but it isn't the most important thing. The most important thing is the ETC principle; that the code is easy to change.

You bring up a good point about something that needs to be added NOW, which is a project management/business/cultural concern and something that needs to be addressed. Compromising code quality for speed is a classical trade of and is probably the reason most professional developers on HN hate their projects.

Funny you bring up that example! I do work at a FinTech org and my 2020 was spent working on a trading platform frontend. (Hell of a year...)

I agree that complexity and quality can be unrelated. I think that quality is often misinterpreted as beauty, or brevity, or cleverness — and those are not the same as quality, in my opinion. Often a long function with a bunch of error and edge case handling is seen as ugly, and thus low quality, and what I’m getting at is that an ugly function can also be quite high quality.

And heh yeah it was on my mind because I just spent a few years at a FinTech too — and a lot of that code is incredibly sensitive, and must contain all kinds of “ugly” condition handling that I don’t think is really low quality, it’s just a complicated problem space that requires a ton of attention to detail. And details can be less fun to read, I think we all can get seduced by code golfing and making things prettier, which is again not the same thing as better.

(Which is I think the point of the article — readability and prose is perhaps key in literature, but not always in software.)

That's a practical design problem, not a fundamentally-necessary evolution of code.

You don’t think handling edge cases and errors is fundamentally necessary?

The real trick is doing both. Code that reads like a short story while including error handling and edge cases. This is achieved in a practical way by first keeping it as simple as possible only implementing strictly necessary abstractions. When the code reaches a "tipping point" then refactor. Rinse and repeat. If the code is structured reasonably that refactor should be mostly limited to the trouble spot.

Lots of good responses here. One thing I'd like to point out:

In my prior job I joined early enough that I was able to keep the codebase very readable. As the team grew, I started running "office hours" to help allow newcomers to onboard. We were a globally distributed team, so it was hard to have the casual interruptions that happen when most of the team is in the same place at the same time.

In my current job I inherited a very crufty codebase, and I've spent a lot of time improving readability. Working with .editorconfig helped; and that initiative took ~1 month!

There are a lot of habits that can be learned by reading code; but mostly the reading is to look at style instead of function or "ideas."

One example of a good habit: My prior role involved a file synchronization product. We followed a naming convention whenever an object represented a file or directory. Merely naming a variable "file" or "directory" would be very confusing, because it lost a lot of context: Is "file" the entry in the SQLite database? Is it the in-memory type that we used to communicate known state about the file? Is it an object that's used to get things about the file from the file system, like last time accessed?

But, and this is where code != literature: The file synchronization product wasn't an "idea." The program was a very detailed set of instructions on how to synchronize files. It handled all the corner cases, because the computer has no ability to make assumptions when it follows these instructions.

Reply on news.ycombinator.com