Hacker News new | ask | show | jobs
by thaumasiotes 1322 days ago
> I long ago concluded that trying to line stuff up in columns like this in code is a mistake. It often results in realignment of blocks for small changes so what should be a small diff in the git history ends up being big.

Seems wrongheaded to me; that's the same reason Elm wanted you to write arrays like this:

    [item1
     ,item2
     ,item3
     ,item4
    ]
instead of a sane way. It means adding or removing an element only changes one line in the diff!

Who cares? It's not hard to understand what's happening in a diff that makes this kind of change. You want the code to be easy to read, not easy to diff.

You could also easily base your diff algorithm on a lexer for the language rather than a lexer for ascii, in which case changing the amount of whitespace would register as "not a change".

3 comments

Many languages also support a comma after the last item, meaning you can still have one line diffs and have a sane reading structure:

    [
      item1,
      item2,
      item3,
      item4,
    ]
Leading comma is better at resolving textual 3-way merges, e.g.:

   [ a         [ a       [ a
   , b         , b    /  , b
   , c   -->   , c   /   , c
   , d         , d  /    , dd
   ]           , e       ]
               ]
Your usual 3 way merge algorithm will correctly deduce:

   [ a
   , b
   , c
   , dd
   , e
   ]
Contrast this with trailing comma:

   [ a,         [ a,       [ a,
     b,           b,    /    b,
     c,   -->     c,   /     c,
     d            d,  /      dd
   ]              e        ]
                ]
You now have a merge conflict between "d," and "dd".

However, if you were to require a trailing comma after the final element you wouldn't have this problem.

> Contrast this with trailing comma:

Example doesn't have a trailing comma. If it did, it would act the same as the leading comma.

But also the leading comma just moves the problem to the beginning of the list instead of the end. Trailing comma with the opening [ on its own line wouldn't have that problem anywhere.

This looks bad. Haskell is much better:

  [ item1
  , item2
  , item3
  , item4
  ]
Compare lisp:

    (item1
     item2
     item3
     item4)
;p