5 ms·
Not going to criticize the article much, because the author is right - sometimes I just don’t like the code/style, so it’s just harder to relate to, not that it
by wruza 4y ago
Not going to criticize the article much, because the author is right - sometimes I just don’t like the code/style, so it’s just harder to relate to, not that it is actually hard to understand.
But there is a single “case” I’d never agree on: the code whose complexity and/or composition ends with nothing. The more experience you get, the more high-level structure you are able to pick on, but sometimes structures are just there, serving nothing at all. Overzealous (or compelled) decomposition into 5-line chunks over tens of files. Pointless renaming, re-exporting and encapsulation. Higher-order code golf. All this done to a finished non-extensible project makes no sense and makes it harder to read, for no reason.
This is a lenghty article, but it is readable in one chunk, a good piece of read. Now imagine the author split it into a number of submodules, then in each they’d give a new name to every phenomenon. Then instead of using English they’d construct a new sub-language (also in modules) to express meaning in a shorter way. E.g. this:
I can’t read the code because I don’t have sufficient experience or expertise (with the language or domain).
I haven’t spent enough time trying to read and understand the code (“it’s not obvious” or “it’s not intuitive”).
I don’t have much interest in understanding this code, I prefer to rewrite it in my own style.
…
turns into this:
With code as object, let me as you negating:
frobnicate causality of read object over sufficient experience or expertise (with the language or domain).
frobnicate relation of enough time and attempt to read and understand object (“it’s obvious” or “it’s intuitive”).
have much interest in understanding object, no prefer to rewrite it in my own style. // “no” negates negation
include more items from [here|https://…].
See frobnicate in my frobnication article.
- xnorswap 4y agoThis is why I hate plug-ins that claim to produce readability or code-cleanliness metrics, because they very typically have the opposite effect. A 1000 line function broken down into 100 different 10 line functions which are then each called in turn (and need lots of parameters to pass around the inevitable shared state) is actually often less readable than just a 1000 line function. The way to deal with such a function to ask why there needed to be a 1000 line function. Why does so much apparently need to be done here and now and so much state shared across so many lines. Code metrics tools would rather you break everything down into micro-functions which if you're blindly trying to follow the tooling recommendations to get it past a check-in gate will probably end up badly named and with little thinking into actual abstraction. If you have two functions but whenever you call function foo = Bar() you have to then call function Baz(foo) then you don't really have two functions at all.
- SemanticStrengh 4y agoThis. A related term being ravioli code.
- danuker 4y agoFor what it's worth, my take on it is that you should extract whatever bits of pure functions you can find in the 1000-line ones. This would help testing and understanding. You can test and understand the parts independently, and only have to test the huge function in order to check that the parts are attached correctly. https://rhodesmill.org/brandon/talks/#hoist https://rhodesmill.org/brandon/talks/#hoist https://danuker.go.ro/the-grand-unified-theory-of-software-architecture.html https://danuker.go.ro/the-grand-unified-theory-of-software-a...
- andi999 4y agoOnly if the pure function have a few parameters and do not need to carry the world.
- danuker 4y agoYou can bundle the parameters into plain/pure/humble objects where it makes sense. https://khanlou.com/2014/12/pure-objects/ https://khanlou.com/2014/12/pure-objects/ http://xunitpatterns.com/Humble%20Object.html http://xunitpatterns.com/Humble%20Object.html
- mannykannot 4y ago'Where it makes sense' is key - otherwise you are just stuffing the wiring behind the desk, adding to the difficulty of understanding it.
- marginalia_nu 4y agoThis a bit of an aside, but I wonder if people would be less prone to advocate pure functions if they had a name that didn't sound like a paladin had come up with them. Would people as eagerly advocate rewriting code to break it into greasy functions?
- usrbinbash 4y ago> Overzealous (or compelled) decomposition into 5-line chunks over tens of files. Pointless renaming, re-exporting and encapsulation. Higher-order code golf. All this done to a finished non-extensible project makes no sense and makes it harder to read, for no reason. Exactly. For decades, people were told this is the way to go, and would somehow, almost magically, make code readable, maintainable, reusable. The result is the exact opposite, a gigantic pile of needless abstractions and spread-out functionality, most of which exist solely to satisfy some paradigms.