Hacker News new | ask | show | jobs
by cjohansson 1545 days ago
If you have consistent code style and formatting this tool is unnecessary. I think that solution is better, you get a more consistent code base that is easier to read for humans. (Also diffs will be faster to compute)
3 comments

> If you have consistent code style and formatting this tool is unnecessary

I disagree. I struggle to replicate it right now using a simple test, but I've seen the following rather infuriating and counter intuitive behaviour from Git/GNU diff. If you have a simple if statement such as:

    if (bla) {
      // do something
    }
And you were to add another statement at the end, after the closing curly brace, e.g.:

    if (bla) {
      // do something
    }

    if (bla2) {
      // do something else
    }
Git/GNU diff will sometimes show the following diff:

    diff --git 1/left 2/right
    index c2ea6f1..dc0e1c2 100644
    --- 1/left
    +++ 2/right
    @@ -1,3 +1,6 @@
     if (bla) {
       // do something
    +}
    +if (bla2) {
    +  // do something else
     }
This is basic example, but there's other similar things. For a simple change like the above, this isn't a huge issue, but for a bigger patch sets, it can take a minute to understand what is really going on.
Right, I frequently get angry at just how dumb diff really is. How it's greedy and can't recognize the best seams between blocks of code. But then when I think of simple rules that would improve the results, I see how they would lead to other problems in other places. So using syntax seems necessary.
There is an option [0] to use non-default but still built-in git diff algorithms that might yield better results.

[0] https://git-scm.com/docs/git-diff#Documentation/git-diff.txt...

I've used a few of the different git diff algorithms and still have had problems like these.
Even if you are consistent, having unchanged indented text show up differently is very clever. I often end up reviewing a diff that moves a basic block into a conditional branch and have to scan each line to see if it changed.
If you're using a language that doesn't depend on indentation (C, Java, Go, Rust etc), try "diff -b" or "git diff -b".

The indented basic block won't show as a difference, only the start and end of the block.

interesting. Is -b equivalent to -Xignore-all-space in git?
I run all python through `black` and `isort`; this is still a huge step up in my book in terms of readability and ergonomics compared to the standard `git diff` or gnu `diff`.