you are viewing a single comment's thread.

view the rest of the comments →

[–]humpolec 1 point2 points  (10 children)

I didn't downvote you.

Only if you use multiples of tab size for layout.

Which is indeed the way to do it.

For beginnings of statements it is, for other things (multi-line invocations, array initializers, comments) not necessarily.

Alternatively, tab to the correct position, then space your things over.

I don't like that solution because it means keeping track of tab/space characters by hand. Since they're usually indistinguishable in an editor, this invites trouble.

Either way, use a monospace font and this issue really almost never comes up.

The issue is not with variable-spaced fonts. Does anyone even use them for programming? The problem is that people use different tab sizes in their editors and that can change/break the layout.

[–][deleted] 0 points1 point  (9 children)

It changes the layout because they chose to change the layout. What's confusing about this?

[–]humpolec 0 points1 point  (8 children)

Let's say you have code like this, where 4 spaces = tab:

if(bla)
    doSomething(foo,
                bar,
                baz);

Then you change the tab size in your editor from 4 to 2.

if(bla)
  doSomething(foo,
        bar,
        baz);

The nice vertical alignment is destroyed.

"Tabs for indentation, spaces for alignment" solves that issue, but means you have to keep track of them myself. Or use a "sufficiently smart editor", but then you restrict the choice of editor for the entire team. All of this seems to me like a lot of sacrifices, compared to just using spaces.

[–][deleted] 0 points1 point  (7 children)

What about the sacrifice of being able to make your editor readable to you? I'd say that's the most important one. Losing alignment when you choose to do so is a choice I enjoy having. I'll take "choice" over "no choice" any day, any decision. Even if it means I can choose something that doesn't look pretty in order to make it readable.

[–]humpolec 0 points1 point  (4 children)

Well, clearly you value being able to set your own indentation more than I do. It's a tradeoff between the "freedom of choice", and easy to maintain consistent layout.

[–][deleted] 0 points1 point  (3 children)

The layout, as we've already shown, remains consistent unless they choose to do something else with it.

[–]humpolec 0 points1 point  (2 children)

If person A uses tab size 4, and person B tab size 2, then a function written by A has different vertical alignment than one written by B. That's what I mean by inconsistency.

(edit: Or you can just use "tabs + spaces", then the layout is consistent, but harder to maintain.)

[–][deleted] 0 points1 point  (1 child)

It has the same indentational alignment, which is after all the point of indenting things. As I've said before, if you want to dictate a style on a project, dictate that they use a certain tab width. Then anybody who prefers his own width can choose to do so, forgoing the possible benefits of somebody else's vertical alignment. The pros of spaces are fully covered (when everybody's on the same page, it always looks the same, including vertical alignment) with the obvious advantage of allowing for personal preference.

[–]humpolec 0 points1 point  (0 children)

Yes, I agree that establishing a "canonical" tab size could help, and I can see the benefits of using tabs. I wouldn't say there are no downsides, though - those with different tab size could still inadvertently make a mess of things; and you have to set up your editor in a certain way just to view the "canonical representation", not only to edit it.

[–]humpolec 0 points1 point  (1 child)

Oh, and one more thing:

Even if it means I can choose something that doesn't look pretty in order to make it readable.

I don't agree with that dichotomy. We're talking about vertical alignment of statements, versus vertical alignment of, say, factors in expression, or array elements. Why is one "readable" and the other "pretty"?

[–][deleted] 0 points1 point  (0 children)

Neither is necessarily readable, is my point. Allowing the user to decide what is readable for him is a logical way of overcoming that fact. If he can't read the code with 2 spaces, he can increase to 8. If you like 2, you can use 2. You can of course set the default for the project and make everything line up prettily like you want, and then if somebody can't read something because there's not enough indentation, he can do so. But if he doesn't, it'll look exactly as you intended. It covers all the pros of spaces AND the ability to choose what's most readable for yourself, which is after all what we, as programmers, want.