[jacquesm]

That's actually right against the style guideline of many projects which tell you explicitly not to do this but to simply put the = sign and value right after the variable name and be done with it. Lining them up serves no purpose and does not in fact make the code easier to read.

[ttty]

To be honest it actually makes code cleaner and therefore easier to read. It's like design have you heard about grid? this is the same thing. Your eyes have to flow the lines. If not everything seems a mess.

[jacquesm]

Ask your revision control system what it thinks about that and your teammates when you submit a 500 line diff for review when a 10 liner would suffice. That's only marginally better than someone checking in a diff when their editor converted tabs to spaces or vv.

Whitespace edits are the code equivalence of wikipedia formatting changes to increase the number of articles you've worked on without actually contributing anything.

Also, if you think that is easier to read you are actually setting yourself up by being deceived by formatting because you'll be skipping bits based on assuming you know what they say. Those are hard lessons to learn but the best way to understand a new piece of code that you're reading is not to read it like a book but like a machine, with a pencil and a notepad tracing the values of the variables as you execute the code in your head (or on the paper if it gets complex). You don't need to run the whole program that way, just the sections that you feel are hard to understand.

[SamReidHughes]

> To be honest it actually makes code cleaner and therefore easier to read.

It does not logically follow from the code being "cleaner" that it is easier to read. Having to scan across a field of whitespace to get to the number makes it harder to read and easier to make mistakes. Having the indentation of the number be unrelated to the length of the variable name adds another aspect that makes it harder to read and easier to make mistakes.

It's also harder to edit, which makes you do fewer edits that make the code materially better.

[wetmore]

It depends on context. For example, here is a function from a project I'm working on:

    parseModifier : String -> Outcome Modifier
    parseModifier s = case s of
      "shift"   -> Ok Shift
      "ctrl"    -> Ok Ctrl
      "alt"     -> Ok Alt
      "meta"    -> Ok Meta
      "command" -> Ok Meta
      "windows" -> Ok Meta
      x         -> Err <| "Unknown modifier: " ++ x

I find it easier to read as is rather than if I dropped the alignment:

    parseModifier : String -> Outcome Modifier
    parseModifier s = case s of
      "shift" -> Ok Shift
      "ctrl" -> Ok Ctrl
      "alt" -> Ok Alt
      "meta" -> Ok Meta
      "command" -> Ok Meta
      "windows" -> Ok Meta
      x -> Err <| "Unknown modifier: " ++ x

As developers we spend more time reading code than editing it. Optimizing for readability seems like a better goal than optimizing for edit speed. Besides, most editors have functionality to align code. When I am looking over a file, the second example looks like a jumble of words to me, while the aligned version seems easier to parse (ha).

[mercurial]

I agree that unaligned switches/pattern matches are bad (and in fact, there is an utility for OCaml which will nicely indent your pattern matches).

[mc808]

I vote for harder to read (and write), except when the variables are so tightly coupled that they should probably be in an array or other structure anyway.

But ideally this is something that should be decided by each developer's personal editor config, like tab widths for indentation.

[greggman]

O'RLY? Does your style guide suggest lining up comments? Why? Does your email app separate things into columns? Do you think it would be more readable if it didn't? How about your bank statement, spreadsheets?

[steveax]

And in fact if there are great differences in the length of the names it makes it harder to read as scanning across and maintaining the correct line becomes more difficult.