4 ms·

That's the cost of abstraction. Abstraction done well is great. But "done well" means specifying the behaviour, all the quirks and corner cases, documenting it

That's the cost of abstraction. Abstraction done well is great. But "done well" means specifying the behaviour, all the quirks and corner cases, documenting it and keeping the docs in sync with the code. That's prohibitively expensive. It's only done, to some extent, for system libraries. So we end up with a lot of badly-executed leaky abstractions. It's a cost problem and with the current economics of software development I see nothing we can do to fix it. But at least we can avoid unnecessary abstraction: Is this function called only from a single place? Yes? Then get rid of it.

zoul 8y ago
But at least we can avoid unnecessary abstraction: Is this function called only from a single place? Yes? Then get rid of it. To me it makes perfect sense to have a function that’s only called from a single place. If the function represents a coherent abstraction (ie. decodeDateStamp, not continueCreatingUser2), then it makes the code easier to read.
- Retra 8y ago
  If it's only called in one place, it should be easier to optimize as well, because the context of the call is clear.
- Benjammer 8y ago
  If it's only called from one place, why not inline it and write a comment? Even just inlined with only the function name you were going to create, as a comment, would be easier to read than a function call to another file. How is that worth the overhead when the function only has one call site?
  - sideshowb 8y ago
    Because bugs per line increase when functions get longer than one screen fold. As well as reducing the conceptual length of your function, bundling up part of it in another function called only once makes a statement, possibly even some guarantees about which variables are and aren't modified by the sub function. It may also decrease the number of variables used in your function and hence the risk of misusing one.
  - MaulingMonkey 8y ago
    Taking this logic to the extreme, several languages let you define functions within other functions. Since everything is ultimately just used by main, why not define everything in main? Well, those local functions usually capture context too, so every local variable of main is now effectively global - with all the difficulties of reasoning about widely shared global state that brings. On large codebases you now have a main function that's millions of lines of code - a bit hard to reason about. In a less extreme example, I more commonly I see functions in the several thousand lines of code range. John Carmack has actually argued for this "style C" at least in some cases: http://number-none.com/blow/john_carmack_on_inlined_code.html http://number-none.com/blow/john_carmack_on_inlined_code.htm... . When it's a simple linear flow like those examples, I'm even relatively OK with that style! But IME clean examples like that are the exception, not the rule. Most functions with thousands of LOC have very high cyclomatic complexity scores too, and are hard to reason about. I have significant trouble keeping track of invariants and edge cases in such code. Ultimately, it can be done, but you have to figure out how to digest such code into bite sized chunks of functionality and what they operate on. Functions declare in code those chunks, imposing some limits on how they interact with other chunks - only interacting through global, member, or input variables. You're forced to give them names, which are much better maintained than the section comments. OTOH - 1 line functions used in one place? I'm quite willing to inline those. And larger functions. There's a sweet spot to cater to - something about how much code you can reasonably keep in your head and reason about all at one time.
- deleted 8y ago
  [deleted]

zoul 8y ago

But at least we can avoid unnecessary abstraction: Is this function called only from a single place? Yes? Then get rid of it. To me it makes perfect sense to have a function that’s only called from a single place. If the function represents a coherent abstraction (ie. decodeDateStamp, not continueCreatingUser2), then it makes the code easier to read.

Retra 8y ago
If it's only called in one place, it should be easier to optimize as well, because the context of the call is clear.
Benjammer 8y ago
If it's only called from one place, why not inline it and write a comment? Even just inlined with only the function name you were going to create, as a comment, would be easier to read than a function call to another file. How is that worth the overhead when the function only has one call site?
- sideshowb 8y ago
  Because bugs per line increase when functions get longer than one screen fold. As well as reducing the conceptual length of your function, bundling up part of it in another function called only once makes a statement, possibly even some guarantees about which variables are and aren't modified by the sub function. It may also decrease the number of variables used in your function and hence the risk of misusing one.
- MaulingMonkey 8y ago
  Taking this logic to the extreme, several languages let you define functions within other functions. Since everything is ultimately just used by main, why not define everything in main? Well, those local functions usually capture context too, so every local variable of main is now effectively global - with all the difficulties of reasoning about widely shared global state that brings. On large codebases you now have a main function that's millions of lines of code - a bit hard to reason about. In a less extreme example, I more commonly I see functions in the several thousand lines of code range. John Carmack has actually argued for this "style C" at least in some cases: http://number-none.com/blow/john_carmack_on_inlined_code.html http://number-none.com/blow/john_carmack_on_inlined_code.htm... . When it's a simple linear flow like those examples, I'm even relatively OK with that style! But IME clean examples like that are the exception, not the rule. Most functions with thousands of LOC have very high cyclomatic complexity scores too, and are hard to reason about. I have significant trouble keeping track of invariants and edge cases in such code. Ultimately, it can be done, but you have to figure out how to digest such code into bite sized chunks of functionality and what they operate on. Functions declare in code those chunks, imposing some limits on how they interact with other chunks - only interacting through global, member, or input variables. You're forced to give them names, which are much better maintained than the section comments. OTOH - 1 line functions used in one place? I'm quite willing to inline those. And larger functions. There's a sweet spot to cater to - something about how much code you can reasonably keep in your head and reason about all at one time.
deleted 8y ago
[deleted]