4 ms·

I like Casey Muratori's idea of removing the word 'abstraction' from your vocabulary in favor of the word 'compression'. You start by writing code absolutely di

by jamii 11y ago

I like Casey Muratori's idea of removing the word 'abstraction' from your vocabulary in favor of the word 'compression'. You start by writing code absolutely directly and then if the same patterns keep cropping up, you compress them into a named pattern. It then becomes clearly a bad idea to try to 'compress' something that you only use once in an attempt to make it simpler. http://mollyrocket.com/casey/stream_0019.html http://mollyrocket.com/casey/stream_0019.html

eru 11y ago
As a sort-of counterexample, it can still be useful to put code that you only use once in its own function: functions have very definite entry and exit points, and a defined interface for communicating with the rest of the code (via arguments, captured variables and return values).
- yoklov 11y ago
  There are several tradeoffs here. Yes, this has a readability benefit, and helps ease developers into the module, especially if they're not familiar with it to start with. A good argument in favor of not breaking them into separate functions is available here[0], basically boiling down to the fact that splitting something into a separate function has the undesirable side effect of hiding the full scope (not in the programming sense) of what it does. If this function is pure, this isn't a problem, but if it manipulates -- or even just accesses -- global state, you might call it when it's in a state that it doesn't expect, leading to subtle bugs. You also might move the call to it to a new location, not realizing the full scope of what it does (this is doubly true for removing calls). [0] https://web.archive.org/web/20150926045718/http://number-none.com/blow/john_carmack_on_inlined_code.html https://web.archive.org/web/20150926045718/http://number-non... (sad to see this site slip away ...)
  - eru 11y ago
    I agree, all bets are off when manipulating global state. (Unless your type system tracks such manipulations in detail.)

by jamii 11y ago

eru 11y ago

As a sort-of counterexample, it can still be useful to put code that you only use once in its own function: functions have very definite entry and exit points, and a defined interface for communicating with the rest of the code (via arguments, captured variables and return values).

yoklov 11y ago
There are several tradeoffs here. Yes, this has a readability benefit, and helps ease developers into the module, especially if they're not familiar with it to start with. A good argument in favor of not breaking them into separate functions is available here[0], basically boiling down to the fact that splitting something into a separate function has the undesirable side effect of hiding the full scope (not in the programming sense) of what it does. If this function is pure, this isn't a problem, but if it manipulates -- or even just accesses -- global state, you might call it when it's in a state that it doesn't expect, leading to subtle bugs. You also might move the call to it to a new location, not realizing the full scope of what it does (this is doubly true for removing calls). [0] https://web.archive.org/web/20150926045718/http://number-none.com/blow/john_carmack_on_inlined_code.html https://web.archive.org/web/20150926045718/http://number-non... (sad to see this site slip away ...)
- eru 11y ago
  I agree, all bets are off when manipulating global state. (Unless your type system tracks such manipulations in detail.)