[linhat]

I really do not understand why they chose to do so. In my opinion, it does not improve readability at all, even worse, when the spacing between type and name gets big, your eyes need more work to figure out the correct line relations.

Furthermore, this can generate horrible commits, for example:

  int x;
  int y;

becomes:

  int   x;
  int   y;
  float z;

after adding ONE single variable. But your commit will contain changes for the above 2 lines. This will make for an insane experience once your variable list grows to a certain size (including multiple spacing changes) and you intend to rollback/cherry-pick/time-warp. Then you will get to deal with the full wrath of conflict resolution. Also, your commit (of one logical line change) contains way to much meta info, which also decreases commit/diff readability.

[forrestthewoods]

If trivial whitespace difference causes wrath fill conflicts then I think you have a deeper issue. I can't think of a situation where this would be even a minor issue.

[peeters]

Not a huge deal, but it hides the actual author of that line when you're doing a blame. I try to only change the precise lines I need to in a commit, and all of them are relevant to the commit message. That way it's usually a very quick check to see what commit added a certain line.

If I absolutely need to do some tidying in a file, I do it in a fully separate commit so that the change can not be construed to be related to the other feature.

[0x0]

Sounds like someone should implement a blame option for "ignore whitespace - show latest author with non-whitespace changes"!

[projct]

git blame -w already does this: http://www.kernel.org/pub/software/scm/git/docs/git-blame.ht...

[binarycrusader]

Mercurial already has this as well:

  hg annotate --help
  ...
  -w --ignore-all-space    ignore white space when comparing lines
  -b --ignore-space-change ignore changes in the amount of white space
  -B --ignore-blank-lines  ignore changes whose lines are all blank

[jonhohle]

git blame -w

[to3m]

If multiple people rearrange the white space at the same time as adding variables (e.g., because the new variables are of types whose names are different widths, both wider than the old gap), you are more likely to get a conflict than if they just leave the spacing alone. Many version control systems seem to tend to do their automated merges line by line, and this sort of edit seems to give them less to work with. [8c99a51796e06219f472f78a5c081dd664da83dc]

Then the wrath comes when you get latest (pull, update, fetch, rebase, call it what you will) and have an inconvenient merge forced on you! I've always personally found the fact that it's just adding or removing white space especially galling :) - but tastes may differ.

[regularfry]

I do use vertical alignment, but that's not necessarily how I'd align the above lines. Assuming y and z are related, but x is not, I'd do them like this:

    int x
    int   y
    float z

I might add a blank line between x and y, too.

If you do vertical alignment such that it emphasises semantic relations, you avoid commits that change more than they should, and it also helps draw your eye to relationships between variables.

[tracker1]

I'll make exceptions myself if there is one declaration that is just way longer...

    int   x
    int   y
    float z
    MyReallyLongTypeHere foo;

Other than that, I tend to prefer having the variable names line up. Though doing mostly JS and C#, I can use var pretty much anywhere an assignment happens, even with null initialization.

    var foo = (sometype)null;

The bigger issue to me is comma first vs comma last... I find that comma first is easier to notice a missing/extra.

[matthavener]

Totally agree and I was really surprised by this. One line patches can turn into 30 lines just to reformat the surrounding code.

[tracker1]

You usually aren't looking for a line based on the type... you're usually looking for a specific variable... with your variables lined up, that portion becomes faster... scanning for y in your second example without the variable declarations lined up for example. This advantage outweighs the slight hinderance of the separation on a given line. That, and many editors will highlight the line with the cursor on it. Which alleviates the issue you point out a bit.

[spc476]

I do that, and I don't find it to be that much of an issue, myself. In my experience, it's rare that I add a new variable to a funtion, so I guess your mileage may vary.