[Dewie]

Right, having tabs seems better since I can configure my editor to display tabs as 4 spaces, while whoever else can have tabs be displayed as 8 spaces. Having spaces instead, and having to make your tabs output spaces, and perhaps also backspace deleting four spaces (a "tab") in certain contexts, seems pretty complex in comparison.

[twic]

Agreed. Using spaces to painstakingly emulate tabs, rather than just using tabs, seems absurd to me.

Even better, if you use real tabs, you might be able to use elastic tabstops:

http://nickgravgaard.com/elastictabstops/

[dezgeg]

In theory, it sounds like a nice idea that by having tabs, you could choose your own preferred indent width of something different than 8 columns. But in practice, this will cause problems, such as code written by you going over the maximum line length when viewed by people with 8 column tabs.

[Dewie]

My editor is set to wrap around on long lines... but that is again of course another thing that potentially has to be tweaked. That is something that is done when writing normal text (like in this text box here on this website), and is done in word processors, so it feels pretty natural.

Though I've used that (wrapping around) mostly when writing in Haskell, for some reason. In Java and whatever lines tend to not become too long, perhaps because I tend to use four space indent...

[scrollaway]

I got into that fight so many times. It baffles me a majority of programmers out there do not understand that tabs are not just a matter of preference, they are a matter of accessibility. I read better on 4-char indent, and some people read better on 8-char indent. Let the user choose, rather than force it with spaces.

[coldpie]

I don't care much either way so long as you NEVER VERTICALLY-ALIGN YOUR LINES.

  int valueone     = 1;
  
  int anothervalue = 2;
  
  float yetmore    = 3.;

Aggggh what a waste of time why do people do this

[edent]

Because I find it really handy to quickly, and visually, check the sanity / logic of something.

In your example, it's really easy to run your eyes down a column and see that one of those values is radically different from the others.

As a trivial example:

    int robert_age = 32;
    int annalouise_age = 25;
    int bob_age = 250;
    int dorothy_age = 56;

I find easier to read as:

    int robert_age     = 32;
    int annalouise_age = 25;
    int bob_age        = 250;
    int dorothy_age    = 56;

Coding styles are about readability and usability. The columns metaphor works well for some categories of data - that's why spreadsheets are so popular.

[coldpie]

This is true if you never change your code. But as soon as I have to add

  int rumpelstiltskin_age = 202;

to your code, I already want to throw you out the window for the work I have to do and the diff I have to ruin to keep your "pretty" formatting. Just don't bother.

[andreasvc]

This ruins the readability and usability of your diffs. Say you need to quickly track down a major bug due to a change in a single constant. With horizontal alignment, the diff might contain any number of changed lines, obscuring the crucial change. There are workarounds that ignore whitespace and word-based diffs, but it's just not worth the trouble IMHO.

[Sir_Cmpwn]

Is this really so bad?

https://gist.github.com/SirCmpwn/540c5fc115e9f65bfa3b

[andreasvc]

The problem I was alluding to occurs when a change causes the amount of alignment spaces to change, which then affects all the lines that have been aligned. Without alignment, the diff would be limited to just the code that was changed.

[chj]

People waste a lot of time in making things pleasant to look at.

[adestefan]

Because emacs does it for me automatically.

[DonHopkins]

The correct term is "horizontal alignment", not "vertical alignment". It's impossible to vertically align code unless you're using a two-dimensional visual programming language.

https://google-styleguide.googlecode.com/svn/trunk/javaguide...

Google Java Style

4.6.3 Horizontal alignment: never required

Terminology Note: Horizontal alignment is the practice of adding a variable number of additional spaces in your code with the goal of making certain tokens appear directly below certain other tokens on previous lines.

This practice is permitted, but is never required by Google Style. It is not even required to maintain horizontal alignment in places where it was already used.

Here is an example without alignment, then using alignment:

    private int x; // this is fine
    private Color color; // this too

    private int   x;      // permitted, but future edits
    private Color color;  // may leave it unaligned

Tip: Alignment can aid readability, but it creates problems for future maintenance. Consider a future change that needs to touch just one line. This change may leave the formerly-pleasing formatting mangled, and that is allowed. More often it prompts the coder (perhaps you) to adjust whitespace on nearby lines as well, possibly triggering a cascading series of reformattings. That one-line change now has a "blast radius." This can at worst result in pointless busywork, but at best it still corrupts version history information, slows down reviewers and exacerbates merge conflicts.

https://developer.mozilla.org/en-US/docs/Web/CSS/vertical-al...

The vertical-align CSS property specifies the vertical alignment of an inline or table-cell box.

Values (for inline elements)

Most of the values vertically align the element relative to its parent element:

baseline: Aligns the baseline of the element with the baseline of its parent. The baseline of some replaced elements, like <textarea> is not specified by the HTML specification, meaning that their behavior with this keyword may change from one browser to the other.

sub: Aligns the baseline of the element with the subscript-baseline of its parent.

super: Aligns the baseline of the element with the superscript-baseline of its parent.

text-top: Aligns the top of the element with the top of the parent element's font.

text-bottom: Aligns the bottom of the element with the bottom of the parent element's font.

middle: Aligns the middle of the element with the middle of lowercase letters in the parent.

<length>: Aligns the baseline of the element at the given length above the baseline of its parent.

<percentage>: Like <length> values, with the percentage being a percent of the line-height property. (Negative values are allowed for <length> and <percentage>.)

The following two values vertically align the element relative to the entire line rather than relative to its parent:

top: Align the top of the element and its descendants with the top of the entire line.

bottom: Align the bottom of the element and its descendants with the bottom of the entire line. For elements that do not have a baseline, the bottom margin edge is used instead.

[Zardoz84]

but looks nice....

[oneeyedpigeon]

Agreed, although this doesn't sit well with me when combined with the reasons for the recommendation - i.e. 8 is just better, line length should be 80, nesting should be limited to 3. If someone can set their indent level to something other than 8, won't they be more likely to violate other rules? I say this having just realised I have my tab set to 4 spaces ...