3 ms·

One has to keep in mind that these thoughts are very language- and application-dependent. In some other languages, programming environments (IDE, static analyze

One has to keep in mind that these thoughts are very language- and application-dependent. In some other languages, programming environments (IDE, static analyzers) or even fields (i.e. less performance-critical) priorities change. Generally, less code is better. Testable functions are better than copy/pasted inline code. Readability is important. Thread-safety is important (if your functions mutate some global state, good luck with that, whether inlined or not...). But it's also hard to argue against the C++ and game programming god himself. As stated in the beginning of the article, these thoughts were from 2007 (not 2014).

latch 8y ago
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 benefits of the non-dogmatic approach. I think why you should use a function is obvious to most of us. But an analysis of when/why you shouldn't, with concrete list of things to look out for, is more significant. Also, I'm not sure that his general goal (improved productivity, fewer bugs in large codebases) isn't a priority in all languages, environment and fields. I also think it's hard to argue that his specific recommendations aren't globally applicable, especially when he uses the word "consider" in many of them. Is there really a language/env/field where you shouldn't consider inlining a function that's only ever called once? Aside, but can we all agree that this is what good technical leadership looks like? It's not some arbitrary law passed down about superficial stuff, it's a thought provoking _discussion_ about code quality. It specifically doesn't argue for a one-size-fits-all appraoch, but rather encourages people to consider the situation on a case by case basis. It also includes a concrete list of actions.
- 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.

latch 8y ago

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 benefits of the non-dogmatic approach. I think why you should use a function is obvious to most of us. But an analysis of when/why you shouldn't, with concrete list of things to look out for, is more significant. Also, I'm not sure that his general goal (improved productivity, fewer bugs in large codebases) isn't a priority in all languages, environment and fields. I also think it's hard to argue that his specific recommendations aren't globally applicable, especially when he uses the word "consider" in many of them. Is there really a language/env/field where you shouldn't consider inlining a function that's only ever called once? Aside, but can we all agree that this is what good technical leadership looks like? It's not some arbitrary law passed down about superficial stuff, it's a thought provoking _discussion_ about code quality. It specifically doesn't argue for a one-size-fits-all appraoch, but rather encourages people to consider the situation on a case by case basis. It also includes a concrete list of actions.

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.