3 ms·

I think you're missing his point; you're on two sides of the same coin. Your both saying "it depends", but he's taking the difficult route and highlighting the

• Nursie 8y ago
  > Is there really a language/env/field where you shouldn't consider inlining a function that's only ever called once? Readability IMHO. Contrast - // This function does three high level things // doHighlevelThing3 is only called once func () { doHighlevelThing1() doHighlevelThing2() doHighlevelThing3() } func doHighlevelThing3 () { doLowlevelStuff1() doLowlevelStuff2() doLowlevelStuff3() doLowlevelStuff4() doSomeBitshifting() writeSomeMemoryLocations() doLowlevelStuff5() doLowlevelStuff6() } With - // This function does three high level things func () { doHighlevelThing1() doHighlevelThing2() doLowlevelStuff1() doLowlevelStuff2() doLowlevelStuff3() doLowlevelStuff4() doSomeBitshifting() writeSomeMemoryLocations() doLowlevelStuff5() doLowlevelStuff6() } To me, the second one loses the readability of the first. There are three main actions func takes, but in the second example we lose the clarity on that. If we bring in all three HighLevel funcs into the low level one, we can end up with something hard to follow and digest, and the intent gets lost. Whether that gets inlined for performance reasons is entirely up to the compiler, IMHO, and if I have very strong feelings I can probably hint to the compiler (making it static in C, private in Java, whatever mechanism in other languages) that it can do what it likes in terms of optimisation.
  • dagw 8y ago
    To me, the second one loses the readability of the first. The second one makes it clear that this function changes the state of something by writing to certain memory locations, the first one doesn't. To me that makes the second one more readable.
    • Nursie 8y ago
      > The second one makes it clear that this function changes the state of something by writing to certain memory locations Seriously? So all state changes need to be made in 'main'? Pretend there was no explicit state change in there, does that change your mind? What if doHighlevelThing3 is actually called "changeTheThing", and the actual write to the memory location is simply the low-level implementation of that? That's a really weird objection (to me, I acknowledge this is all style and I am opinionated).
      • latch 8y ago
        Carmack has been consistent for a long time that state changes are a major source of bugs. It's true that video games might be more susceptible to this. I think all things considered, readability should generally take a back seat to correctness. I mean, the code is readable, yay!, but the game crashes randomly...not so yay... Also, he does offer a suggestion to help address your concern: "Using large comment blocks inside the major function to delimit the minor functions is a good idea for quick scanning, and often enclosing it in a bare braced section to scope the local variables and allow editor collapsing of the section is useful." Finally, note that he's only suggestion that you CONSIDER it, which was my original point. It's hard to say his suggestions are wrong, when his suggestions are merely that you consider it.
        • Nursie 8y ago
          > I think all things considered, readability should generally take a back seat to correctness. I think that lack of readability is a sure path to lack of correctness, personally. Carmack may have had the luxury of working with consistently great engineers... I do not :) I'm not saying his suggestions are wrong, merely that there are times when encapsulation makes sense. Code can be readable and correct.