On Bricks and Code | Hacker News Reader

On Bricks and Code

tombartel.de

6 pointstbartel4 comments

Author here, comments welcome.

I don't disagree w/ your attidude towards the LOC metric, and I especially like your idea in the footnotes about each line of code being a tax on future programmers who have to read the code. I'm afraid that the code example itself is a bit hand-wavy though, since you introduce a "downloadAsync" function that needs to be implemented differently for each example. So I thing your argument could be strengthened with a more concrete code sample. Continuing the money/tax analogy, if each line of code represents a tax to be paid each time the code is read, then the cost of understanding the code with fewer lines represents an "entrance fee" that would be a barrier to less-experienced devs. I could see how even a technically-minded manager might appreciate the code with the lower barrier to entry -- and justifying their continued use of the LOC metric thereby.

Thanks for your comment. I see your point with the missing implementation of "downloadAsync()".

About the "entrance fee": Do you really feel that the shorter version is more difficult for less-experienced devs to understand? The verbose version is unlikely to be easily understandable, in my opinion.

In general, I don't think that more lines of code make something more readable.

The "entrance fee" in this case would be: understanding promises. When you introduce a new feature into a language, my assumption is that a "less-experienced dev", by definition, would not have experience using promises in production. So if you're going to sprinkle in higher-level (or just new) concepts into your code, you're assuming a certain level of experience for the devs who will come after you. If, instead, you sort of "spell everything out", it will take more words to do that, but you aren't referencing an assumed set of shared knowledge.

If anything, I think it would help to identify what assumptions are inherent in our code, and at least point to references for a "less-experienced dev" in the comments. A comment that said: "Hey you! This code uses promises, so if you don't know about those, check out this ref: [URL]", would be extremely helpful in this case.

Reply on news.ycombinator.com