4 ms·
I think that some codebases can lend themselves to be read more than others. Consider for example GNU cat[0] vs. Plan9's[1], from which one can infer the overal
by mbivert 3y ago
I think that some codebases can lend themselves to be read more than others. Consider for example GNU cat[0] vs. Plan9's[1], from which one can infer the overall readability of the two projects.
In particular, codebases who are composed of small, well-isolated components, can be read one chunk at a time, like a book. But I wouldn't be surprised for most "professional grade" codebases to consist of organic, "cluttered" aggregate. Which, as you observe, aren't really suited to be read, even more so linearly.
It also depends on one's intents, which are likely narrower in a professional setting (e.g. fixing a bug, implementing a feature; refactoring being a notable exception), than in a learning setting (e.g. learning how to write idiomatic parsers in Go by studying the Go parser itself). In this last case, curiosity might push you to read the code more deeply, compare different codebases, etc.
Finally, some languages also are more prone to enforce locality than others, impacting readability. See for example Linus arguing about C being more context-free than C++ [2].
[0]: https://github.com/pete/cats/blob/master/gnu-cat.c https://github.com/pete/cats/blob/master/gnu-cat.c
[1]: https://github.com/pete/cats/blob/master/plan9-cat.c https://github.com/pete/cats/blob/master/plan9-cat.c
[2]: https://www.realworldtech.com/forum/?threadid=104196&curpostid=104299 https://www.realworldtech.com/forum/?threadid=104196&curpost...
- jrmg 3y agoThanks. I’ve definitely ‘read’ things like both those ‘cat’s in the past. Even the GNU one is still small enough to be understood. I agree with what you said about larger projects and the intent behind ‘reading’. Linus’s opinion is interesting. I wonder how it’s changed over the years. I share his disdain for operator overloading on a visceral level, but to be fair it’s not much different to method or function naming really - those can end up misleadingly similarly named in large code adds too.
- mbivert 3y agoI guess we can put things this way: the closer the codebase is to a collection of uncorrelated chunks, the more one can read it "systematically". OTOH, the more the dependencies between the various chunks, the more useful/efficient a "reverse-engineering reading" becomes. "Bad" naming, operator overloading, both add such dependencies. As a side note regarding operator (well, symbol) overloading: it's just plain awful in mathematics: e.g. a "+" signs can refer to an actual operator between scalar, between vectors, between functions, between spaces, an essentially syntactical element (portion of a name), etc. It makes simple things so hard to understand for novices.
- theonething 3y agowow, GNU's is just gobbledygook