Two Star Programming

Your argument is like trying to claim that twenty lines of string munging is more readable than a straightforward regex. That's only true if you don't really get regular expressions.

If you understood pointers well enough, you would see Linus's version as more readable. The other one has so much more unnecessary fluff that makes it extra complicated and less readable. If you don't understand pointers well enough, and "haven't seen this before", of course you'll find it confusing.

Readability is in the eye of the beholder.

That reminded me of this quote: "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

http://en.wikiquote.org/wiki/Brian_Kernighan

My personal rule of thumb concerning pointers is that two-stars should never be seen except in the case where you want a function to be able to modify a pointer that was passed in as a parameter. That's it. If I get handled a module that has two-stars in it under any other circumstance, I refactor it. I do this because:

a) lots of people find it difficult to thing about pointers to pointers (although I've never understood why empirically I note that this is the case).

b) Having to dereference two pointers to get to the information that you want is not just slow because of extra work needing to be done, but also because you've just increased the need for doing a page change in memory, which on some architectures can be surprisingly expensive.

It certainly shouldn't. There's no difference at an architectural level between keeping track of prev and keeping track of &prev->next (as should be obvious, because they differ by a constant offset): advancing in the list is just a pointer update via a load either way, and removing a link is just a store.

Since they do the same thing, the opportunity for an LHS stall may be avoided in either approach with a little care.

Readability and maintainability trump developers showing how clever they are by far.

My rule of thumb is I can write “clever” code if I make sure it would be easy to debug for me or anyone else. This usually includes indented logging for anything complicated, good choice of variable names and plenty of debug assertions that would fail with a meaningful message if something went wrong.

When the deadline comes and you're dealing with an obscure bug in a clever code that looks right but is difficult to reason about, you'll be damning it.

How was this not easy code to write? I imagine it would have looked like this, but in your language of choice:

  (defun remove-if (lst pred)
     (if (null lst)
         nil
         (if (funcall pred (first lst))
             (remove-if (rest lst) pred)
             (cons (first lst) (remove-if (rest lst) pred))
             )
         )
      )

    node *remove_if(node *head, remove_fn rm)
    {
        if (rm(head)) {
            return remove_if(head->next);
        }
        head->next = remove_if(head->next);
        return head;
     }

    #define max(a, b) ((a) > (b) ? (a) : (b))
    #define geth(n) (n->h = 1 + max(n->l->h, n->r->h))
     
    struct node
    {
          int key, h;
          struct node *l, *r;
    } *R, *NIL;
    typedef struct node node;
     
    void init(void)
    {
          R = NIL = (node *) malloc(sizeof(node));
          NIL->key = NIL->h = 0,
                  NIL->l = NIL->r = NULL;
    }
     
    node* rotleft(node *n)
    {
          node *t = n->l;
     
          n->l = t->r, t->r = n,
                  geth(n), geth(t);
          return t;
    }
     
    node* rotright(node *n)
    {
          node *t = n->r;
      
          n->r = t->l, t->l = n,
                  geth(n), geth(t);
          return t;
    }
     
    node* balance(node *n)
    {
          geth(n);
          if (n->l->h > n->r->h + 1)
          {
                  if (n->l->r->h > n->l->l->h)
                          n->l = rotright(n->l);
                  n = rotleft(n);
          }
          else
                  if (n->r->h > n->l->h + 1)
                  {
                          if (n->r->l->h > n->r->r->h)
                                  n->r = rotleft(n->r);
                          n = rotright(n);
                  }
          return n;
    }
     
    node* insert(node *n, int key)
    {
          if (n == NIL)
          {
                  n = (node *) malloc(sizeof(node));
                  n->key = key, n->h = 1, n->l = n->r = NIL;
                  return n;
          }
          if (key < n->key)
                  n->l = insert(n->l, key);
          else
                  n->r = insert(n->r, key);
          return balance(n);
    }
     
    node* erase(node *n, int key)
    {
          node *t;
          if (n == NIL) return n;
          if (n->key == key)
          {
                  if (n->l == NIL || n->r == NIL)
                  {
                          t = n->l == NIL ? n->r : n->l;
                          free(n); return t;
                  }
                  else
                  {
                          for (t = n->r; t->l != NIL; t = t->l);
                          n->key = t->key,
                                  n->r = erase(n->r, t->key);
                          return balance(n);
                  }
          }
          if (key < n->key)
                  n->l = erase(n->l, key);
          else
                  n->r = erase(n->r, key);
          return balance(n);
    }
     
    int search(node *n, int key)
    {
          if (n == NIL) return 0;
          if (n->key == key) return 1;
          if (key < n->key)
                  return search(n->l, key);
          else
                  return search(n->r, key);
    }

This was actually one of the very first questions we used to ask during interviews at Tenable. I'm honestly kind of amazed it's now seen as some sort of tricky technique. I would think (or hope) most C programmers would see it as basic competence with pointers.