4 ms·

I like Carmack's approach to functions the best: "If a function is only called from a single place, consider inlining it. If a function is called from multipl

I like Carmack's approach to functions the best: "If a function is only called from a single place, consider inlining it. If a function is called from multiple places, see if it is possible to arrange for the work to be done in a single place, perhaps with flags, and inline that. If there are multiple versions of a function, consider making a single function with more, possibly defaulted, parameters. If the work is close to purely functional, with few references to global state, try to make it completely functional. Try to use const on both parameters and functions when the function really must be used in multiple places. Minimize control flow complexity and “area under ifs”, favoring consistent execution paths and times over “optimally” avoiding unnecessary work." http://number-none.com/blow/blog/programming/2014/09/26/carmack-on-inlined-code.html http://number-none.com/blow/blog/programming/2014/09/26/carm...

jacquesm 4y ago
> If a function is only called from a single place, consider inlining it. A compiler should do this for you. > If a function is called from multiple places, see if it is possible to arrange for the work to be done in a single place, perhaps with flags, and inline that. This makes no sense to me. > If there are multiple versions of a function, consider making a single function with more, possibly defaulted, parameters. This can be useful, but only if it does not mess up code readability unless you are trying to squeeze your code into a cache. > If the work is close to purely functional, with few references to global state, try to make it completely functional. This makes very good sense, but it can be harder than it seems. One of the easiest ways (depending on how far down the call stack you are) you may just be able to pass the individual parts of that global state in as parameters. > Try to use const on both parameters and functions when the function really must be used in multiple places. Not all languages support this, but where they do this is good practice. In general: limiting scope and mutability is always an advantage. > Minimize control flow complexity and “area under ifs”, favoring consistent execution paths and times over “optimally” avoiding unnecessary work. Is also good advice. In general you want to avoid nesting your ifs too deeply because at some point you lose track of what the local context is that got you there. Then it is usually better to break out a function and name it well so that that context is clear again. In general, naming things well is hard.
- Jensson 4y ago
  > A compiler should do this for you. Point of inlining is to make it explicit that it is an ad hoc implementation for that location, so you don't have to be afraid of adding more stuff in it just to solve a local problem.
  - jacquesm 4y ago
    Easily solved with a comment and that frees you up from using it in more than one place if you ever feel like it. Inlining is a very low level implementation detail, I think making that explicit is something that you only want to do if you are breaking out the function for clarity and to be able to name it when it only lives in a single location. A bit like an assembly macro.
    - Jensson 4y ago
      Not sure what a comment would solve. The point is that if you are making an ugly implementation for some reason, then inlining that is the right choice, breaking it out into a function that can only safely be called in that exact spot is by far the worst technical debt you can create. If you have a pile of shit then don't put it on a fan and spread it all over the room, isolate it so you know where it is and other parts can ignore it easily.
- userbinator 4y ago
  A compiler should do this for you. Unless it outputs source code, it can't.
  - jacquesm 4y ago
    From what I got the context he more or less implied a compiler due to the language used (C++). I know that's now how C++ started but nowadays I think you can assume that when people discuss ways to program C++ it is by using a compiler rather than a code generator.
    - 4y ago
KerrAvon 4y ago
Yeah, but read the very top of that post for his updated thoughts. The problem with manually inlining large functions is that they make code impossible to follow or reason about, which over time means that they turn into spaghetti code because people get lazy about reusing pieces from random other places in the same function. His later addendum is important not to omit, because this is really the key to more reliable code: > The real enemy addressed by inlining is unexpected dependency and mutation of state, which functional programming solves more directly and completely. However, if you are going to make a lot of state changes, having them all happen inline does have advantages; you should be made constantly aware of the full horror of what you are doing. When it gets to be too much to take, figure out how to factor blocks out into pure functions (and don.t let them slide back into impurity!).
siva7 4y ago
That would lead to a Big Ball of Mud if given to an inexperienced or reckless developer as i've witnessed many times in my career. The problem with such best practices/patterns/thought pieces is that they stem from highly experienced developers but given to the inexperienced they are like a hand grenade in the hands of an ape.
- xtian 4y ago
  That’s true of every methodology used by inexperienced or reckless developers. There is no shortcut to quality or experience. But Carmack’s approach has the distinction of ultimately delivering results by orienting one towards the objective necessities of the problem at hand rather than, for instance, the never-ending spiral of arbitrary and inefficient abstractions that OO ideology commonly produces.
- gladiatr72 4y ago
  It is like claiming you can teach someone how to read by having them watch and emulate already proficient readers. Hrm...
c3534l 4y ago
This feels like an alternative way of thinking about DRY. Make the running progra@ not have to repeat itself.
bambax 4y ago
> If a function is only called from a single place, consider inlining it. The main keyword is consider. Sometimes it's a good idea, and sometimes (often) it isn't.
jakelazaroff 4y ago
Man, I really disagree with those first three. Branches should be avoided whenever possible, not leaned into. Especially within abstractions.

jacquesm 4y ago

> If a function is only called from a single place, consider inlining it. A compiler should do this for you. > If a function is called from multiple places, see if it is possible to arrange for the work to be done in a single place, perhaps with flags, and inline that. This makes no sense to me. > If there are multiple versions of a function, consider making a single function with more, possibly defaulted, parameters. This can be useful, but only if it does not mess up code readability unless you are trying to squeeze your code into a cache. > If the work is close to purely functional, with few references to global state, try to make it completely functional. This makes very good sense, but it can be harder than it seems. One of the easiest ways (depending on how far down the call stack you are) you may just be able to pass the individual parts of that global state in as parameters. > Try to use const on both parameters and functions when the function really must be used in multiple places. Not all languages support this, but where they do this is good practice. In general: limiting scope and mutability is always an advantage. > Minimize control flow complexity and “area under ifs”, favoring consistent execution paths and times over “optimally” avoiding unnecessary work. Is also good advice. In general you want to avoid nesting your ifs too deeply because at some point you lose track of what the local context is that got you there. Then it is usually better to break out a function and name it well so that that context is clear again. In general, naming things well is hard.

Jensson 4y ago
> A compiler should do this for you. Point of inlining is to make it explicit that it is an ad hoc implementation for that location, so you don't have to be afraid of adding more stuff in it just to solve a local problem.
- jacquesm 4y ago
  Easily solved with a comment and that frees you up from using it in more than one place if you ever feel like it. Inlining is a very low level implementation detail, I think making that explicit is something that you only want to do if you are breaking out the function for clarity and to be able to name it when it only lives in a single location. A bit like an assembly macro.
  - Jensson 4y ago
    Not sure what a comment would solve. The point is that if you are making an ugly implementation for some reason, then inlining that is the right choice, breaking it out into a function that can only safely be called in that exact spot is by far the worst technical debt you can create. If you have a pile of shit then don't put it on a fan and spread it all over the room, isolate it so you know where it is and other parts can ignore it easily.
userbinator 4y ago
A compiler should do this for you. Unless it outputs source code, it can't.
- jacquesm 4y ago
  From what I got the context he more or less implied a compiler due to the language used (C++). I know that's now how C++ started but nowadays I think you can assume that when people discuss ways to program C++ it is by using a compiler rather than a code generator.
  - 4y ago

KerrAvon 4y ago

Yeah, but read the very top of that post for his updated thoughts. The problem with manually inlining large functions is that they make code impossible to follow or reason about, which over time means that they turn into spaghetti code because people get lazy about reusing pieces from random other places in the same function. His later addendum is important not to omit, because this is really the key to more reliable code: > The real enemy addressed by inlining is unexpected dependency and mutation of state, which functional programming solves more directly and completely. However, if you are going to make a lot of state changes, having them all happen inline does have advantages; you should be made constantly aware of the full horror of what you are doing. When it gets to be too much to take, figure out how to factor blocks out into pure functions (and don.t let them slide back into impurity!).

siva7 4y ago

That would lead to a Big Ball of Mud if given to an inexperienced or reckless developer as i've witnessed many times in my career. The problem with such best practices/patterns/thought pieces is that they stem from highly experienced developers but given to the inexperienced they are like a hand grenade in the hands of an ape.

xtian 4y ago
That’s true of every methodology used by inexperienced or reckless developers. There is no shortcut to quality or experience. But Carmack’s approach has the distinction of ultimately delivering results by orienting one towards the objective necessities of the problem at hand rather than, for instance, the never-ending spiral of arbitrary and inefficient abstractions that OO ideology commonly produces.
gladiatr72 4y ago
It is like claiming you can teach someone how to read by having them watch and emulate already proficient readers. Hrm...

c3534l 4y ago

This feels like an alternative way of thinking about DRY. Make the running progra@ not have to repeat itself.

bambax 4y ago

> If a function is only called from a single place, consider inlining it. The main keyword is consider. Sometimes it's a good idea, and sometimes (often) it isn't.

jakelazaroff 4y ago

Man, I really disagree with those first three. Branches should be avoided whenever possible, not leaned into. Especially within abstractions.