3 ms·
That was a really interesting article. I completely agree with >>> Abstractions may make things easier to extend in the future, or guard against certain types
by FullyFunctional 7y ago
That was a really interesting article. I completely agree with
>>> Abstractions may make things easier to extend in the future, or guard against certain types of errors, but they need to be considered against the fact that you may end up with 3 times the amount of code to understand and refactor, 3 times the amount of possible locations for bugs and less time left to spend on testing and further development.
Choosing when and how to abstract is key. Abstraction in a fashion extends the language so you are trading off a burden on the reader (who have to learn and trust the abstraction) for increased expressiveness. Don't overdo it. (And don't abstract idioms).
- mhh__ 7y agoI think thinking carefully about the abstractions is also key, ideally not while at the computer. Good abstractions should be obvious and not really requiring refactoring as per se.
- rjayatilleka 7y agoCould you clarify what you mean by "don't abstract idioms?"
- FullyFunctional 7y agoOne example (taken from the real world): addr = (addr + PAGESIZE - 1) & ~PAGESIZE; contrast with addr = P2ALIGN(addr); The former is idiomatic and immediately readable. For the latter I have to go lookup the definition of P2ALIGN (and make sure I got the one actually used as there may be multiple!), check that it does what I expect, and memorize it. The value of abstracting the idiom is debatable. If it _is_ used sufficiently often, then it might be worthwhile, but often it isn't.