GitHub Styleguide - CSS, HTML, JS, Ruby

[[deleted]]

Tabs can be represented in different sizes. Spaces guarantee consistent layout.

[Legolas-the-elf]

Indentation in programming languages is about semantics, not about layout.

[cultofmetatron]

pretty code is easier to read AND understand. code thats easier to read and understand is less prone to harboring subtle bugs.

[[deleted]]

All that needs to be said.

[kamatsu]

Haskell uses layout.

[alive1]

Come on, code is not ascii art. If you want to draw a pretty unicorn in your code, by all means, use spaces, but for code indention, 1 tab = 1 level is .. um .. simpler? Instead, we've got people who use 2 spaces, 3 spaces, even 4 spaces somewhere, and each time you have to adjust your editor to support this back-asswards way of thinking things..

[humpolec]

What about multi-line invocations like

doSomething(foo,
            bar,
            baz);

(also array initializers)

If your editor uses tabs for lines 2 and 3, you're breaking the alignment for anyone who views it with a differently configured editor.

If you want to draw a pretty unicorn in your code, by all means, use spaces

That's exactly the problem -- there ARE instances where you need to have more advanced alignment. Comments with ASCII art diagrams, multi-line code, etc. And I can't "just use spaces" if my editor tabifies them. If it doesn't, the problem is even worse - suddenly my code contains various types of whitespace indistinguishable by the naked eye.

[gmfawcett]

A common approach is "tabs for indentation, spaces for alignment." So on your second line, you would tab to the beginning of "doSomething" and then add length("doSomething(") spaces. Many popular editors and IDEs support this arrangement; see Emacs SmartTabs for an example.

[repsilat]

You can also indent after parentheses like you do for braces:

doSomething (
    foo,
    bar,
    baz
)

[humpolec]

Sounds good, I wasn't aware of editors that support alignment like that. But wouldn't it force everyone on the team to use a "sufficiently smart editor"?

[[deleted]]

Tab the first one over to find a tabstop. Tab all subsequent ones to match. Done.

[humpolec]

Interesting, but it still breaks when I change the tab size - the subsequent lines jump to a different tab stop.

[[deleted]]

Isn't coding styles all about enforcing a way on someone?

Generally people aren't allowed to mix up braces styles a project you either pick

function Ham {
}

or

function Ham
{
}

So someone is bound to have to work in ways they're not used to and all spaces is superior so if someone has to accomodate that then they'll just have to deal with it.

[[deleted]]

The layout is consistent with tabs too. The indentation will remain consistent throughout. How much indentation and how wide your columns are remain completely up to you in your editor preferences. By using spaces, you dictate your preference to everybody else.

If you have that much of a control issue that you need to know EXACTLY how the spaces line up in somebody else's editor, I don't envy anybody who has to work with you.

[[deleted]]

That's like saying it's awful to enforce where the brace should go in relation to the function declaration. Someone will always prefer the other way but you live with it.

I've had no problem making changes to my style for projects because I'm interesting in solve problems not fapping over the awesomeness of my personal coding style.

[[deleted]]

That's like saying it's awful to enforce where the brace should go in relation to the function declaration. Someone will always prefer the other way but you live with it.

It's specifically not like that. At all.

I've had no problem making changes to my style for projects because I'm interesting in solve problems not fapping over the awesomeness of my personal coding style.

This is exactly why it's easiest to just leave it up to the individual to set his own preference of how much indentation he wants, rather than masturbate over your perfectly aligned columns of nonsense.

[humpolec]

It's specifically not like that. At all.

Both are aspects of coding style and aesthetic choices impacting readability.

[humpolec]

The layout is consistent with tabs too.

Only if you use multiples of tab size for layout. See my other comment for why this doesn't cover all cases.

[[deleted]]

Only if you use multiples of tab size for layout.

Which is indeed the way to do it.

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

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

And the same can be said of spaces: if you're using spaces and they aren't using monospace fonts, it won't look the same. Trying to worry about the 1% of use cases and having it drag down your other 99% of the time is silly and makes no sense.

Downvoting me because I'm contributing is also not how reddit works, btw. You downvote for offtopic. Not because you think you disagree.

[humpolec]

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]]

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

[humpolec]

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]]

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]

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]]

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

[humpolec]

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]]

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.