5 ms·
First, I think we should use expression count instead of pure LOC because many styles add white space but keep the expression the same. I don’t consider one sty
by rcme 3y ago
First, I think we should use expression count instead of pure LOC because many styles add white space but keep the expression the same. I don’t consider one style “more terse” than another. e.g.
a.map(…).reduce(…).join(…)
a.map(…)
.reduce(…)
.join(…)
If you can accept that expressions are a better metric for “terseness” then I will categorically say your statement is pretty easy to disprove. Essentially you’re saying that every 10 expressions can be rewritten as a single expression. I don’t believe that to be true, based on a cursory glance of some code bases I’m familiar with.
- taeric 3y agoMost any metric can be gamed. At large, though, I'd wager that the noise from these scattered through a codebase are minimal to the point. That said, I do think I agree that tooling is good enough now that you can probably try both counts and see what can be seen. With the idea that these are not precise numbers into complexity, but directional concerns.
- ssivark 3y agoThe spirit of the claim is to reduce the number of expressions by 10x while only sacrificing the “unnecessarily complicated” functionality. It is a question of system design that demands judgement, and not just a raw code length compression. It’s about preventing large (and poorly thought out) projects from being worked on in the first place, before they need to be scrapped or circumvented.
- nijave 3y agoCode generation is also pretty prevalent, some languages/ecosystems more than others