John Carmack on Inlined Code(number-none.com)

    val result1 = {
      val bar = barFromFoo1(foo)
      // ...
      baz.awesome()
    }

    val result2 = {
      val bar = ... // unrelated to 'bar' above
      bar.awesome()
    }

    AwesomenessT largerFunction(Foo1 foo1, Foo2 foo2)
    {
        ResultT1 result1 = [&] {
            Bar bar = barFromFoo1(foo1);
            Baz baz = bar.makeBaz();
            return baz.awesome();
        } ();

        ResultT2 result2 = [&] {
            Bar bar = barFromFoo2(foo2);
            return bar.awesome();
        } ();

        return result1.howAwesome(result2);
    }

    const auto values = [&] {
        std::vector <int> v (n);
        std::iota (begin (v), end (v), 0);
        std::shuffle (begin (v), end (v), std::mt19937 {seed});
        return v;
    } ();

    void largerFunction(void) {
        small1();
        small2();
    } where {
        void small1(void) {
            ...
        }
        void small2(void) {
            ...
        }
    }

    while true:
      ...
      if (!wasDead && dead) startFadeOut()
      ...
    
      wasDead = dead
      doPhysics()

    > "The function that is least likely to cause a problem is one that doesn't exist, which is the benefit of inlining it."
    > That's the equivalent of saying "the faster you drive the safer you are b/c you're spending less time in danger"

  To make things more complicated, the .do always, then 
  inhibit or ignore. strategy, while a very good idea for 
  high reliability systems, is less appropriate in power and 
  thermal constrained environments like mobile.

    let a = f () in a + a

    f () + f ()

    Besides awareness of the actual code being executed, inlining functions also 
    has the benefit of not making it possible to call the function from other 
    places. That sounds ridiculous, but there is a point to it. As a codebase grows 
    over years of use, there will be lots of opportunities to take a shortcut and 
    just call a function that does only the work you think needs to be done. There
     might be a FullUpdate() function that calls PartialUpdateA(), and 
     PartialUpdateB(), but in some particular case you may realize (or think) that
     you only need to do PartialUpdateB(), and you are being efficient by avoiding 
     the other work. Lots and lots of bugs stem from this. Most bugs are a result 
     of the execution state not being exactly what you think it is.