Death to the Space Infidels!

ok, let’s settle this. I created a (Survey Monkey) survey to quantify people’s preferences: a href= tabs vs spaces?/a

Apparently Survey Monkey does not share the survey results with people taking the survey, but I promise to post the results here after a day or two.

fixed link:

When dealing with javascript or CSS or HTML, if you use spaces instead of tabs, wouldn’t that significantly increase the size of your response? The byte-count of the codefiles and markup files are bigger, which means that there’s just that many more wasted bytes that have to be transmitted. I’m sure HTTP compression can help, but even with it, I’d bet that there is a performance benefit to using tabs (or removing basically all whitespace, but that’s a bit extreme). It’s probably not a huge deal, but if you’re ultra-concerned about performance, every millisecond helps.

And if you’re going to use tabs in your HTML, javascript, and CSS, why not the rest of your codefiles?

I’m not completely opposed to using spaces instead of tabs, but if you’re going to do it, I’d absolutely agree that you have to define a standard (I’d say 4 spaces) and stick with it across your company, with no exceptions for any reason.

@Joe Enos
Most people minify ( ) their html/javascript/css code.

I rather dislike my tabs becoming spaces, though now that I’m in Visual Studio most of the time, I just let it do it’s magic.

One point, however, vim can totally fake tab stops using a plugin:

I prefer tabs over spaces and let them be two spaces wide, so I don’t waste to much space and have the opportunity to spaghetti my code up!

I also do this (JavaScript):

function getSomething(){
/* Very much code. */
return ‘something’;}

Code looks very much like Python then!

I’m sure a lot of people do minify their stuff, but try doing a view source on a dozen random web apps out there, and also view their javascript and css files - I’d bet more than half don’t do any minification, and several more do only a little bit. It’s a nice concept in theory to minify all your stuff, but it’s a little more challenging in practice - otherwise I’m sure everyone would do it.

Hey, anyone remember make? Just make sure that tab is a tab, not a bunch of space, hehe :slight_smile:

Tabs. Then you can dynamically adjust how deep your indentation is. There’s just no excuse to use spaces.

Spaces also don’t work if you use a variable-length font.

Variable-width font in code? You’d have to be smoking some serious stuff if you’re using that.

Apparently my 2008 IDE isn’t modern enough when it comes to shielding me from the tab/space impedance mismatch.

I want # Tabs == # Backspaces.

I want # Tabs == # arrow key presses (for navigation and text selection).

For these reasons, tabs currently give me the best editing experience. We all know that editing code consumes more of our time than writing greenfield code, so I would argue that tabs result in greater productivity than spaces.

I only hit the tab button to get me x spaces indented, and usually with reformatting GUI’s I don’t even have to hit tab all that often.

I don’t care about tabs, and I don’t care about spaces, but I do care about the reduced comprehension when reading oddly formatted code.

But there is a bigger problem, and it’s 10 different people skinning the cat in 10 different ways, and indentation is but a small part of it.

I like how Agile treats it. Code is common and belongs to everybody. It’s not your own pet project, so express your individuality not in code, but in clothing or decorating your office. Get a perm. You should not be able to distinguish who wrote the code, ever. When your team can achieve this, all members of your team will benefit by not suffering cognitive dissonance when reading unfamiliar code.

program statements were arranged in a sensible order, experts were able to remember them better than novices. When statements were shuffled, the experts’ superiority was reduced

My browser must have missed a couple paragraphs in the download. How do you get from this to tabs/spaces? I can see how putting things in the wrong order makes it harder, but I don’t see how that applies to what character code you use for pushing your statements to the right. With the right editor settings, you can’t even tell the difference just by looking.

Surely, even if I admit that one’s memorization skills are affected by their order (which I think is reasonable), I don’t see any reason to jump to the conclusion that they’re affected by something which is, by definition, invisible.

Do you also think it is harder to remember things about some source code if it uses different linefeed characters, or a different Unicode encoding, or is stored on a different filesystem? Because these things sound exactly as relevant to me.

Here’s my take…

There is a fundamental tension between wanting to reformat the code and wanting to avoid reformatting the code. We want to reformat so we can read and understand. We want to avoid reformatting because it pisses off our coworkers and interferes with source control history.

We can break this tension by breaking the link between how the code is stored and how it is displayed. It is a classic model-view-controller problem. Editors should have a display pretty but don’t change it mode.

The display mode could allow full control of all aesthetic parameters including indent, space around parens, new lines before braces, etc.

When saving, the editor would make a few changes as possible. Opening white space would be preserved on existing or changed lines. Opening white space would follow the convention of near by code for new lines.

I think this would make everyone happy.

*[…] or MUMPS. (BTDT).

Who writes code with variable length fonts? That’s just heresy.

The problem I have with tabs is that it will inevitably lead to Jeff’s third case at some point. I’ll want to align something across two rows and with tabs you could end up with mismatching alignment as soon as someone with different spacing settings opens it up. Spaces solve this.

Most IDE’s (and even things like Vim) have smart intending anyway, so I rarely have to manually tab or space for anything.

I like the way InType handles it: you can set it to either use spaces or tabs, and you can set how far a tab length is. By default it’s 4; you can change it to 2, 8, whatever.

If there was a backtab key, then I could live with space insertion on pressing the Tab key. But there is not, and few things annoy me more than having to backspace my way through 5 or 6 tabs in the middle of a line.

Tab is a dedicated key on a keyboard. It has a use. On typewriters it moves to the next tab stop, there’s NO REASON to overload this.

And… I have to say, 2 spaces is NOT sufficient for indented code legibility.

I also note that if you use VS200X’s Format Document, you get TABS out of the box, not spaces, and they are 4 spaces long. When in doubt, use what you’re given as the convention.

How about we stop using text format for code or have smarter tools. Instead of the current line based approach, have diff tools that can indicate that methods have been moved, changed signature etc. Changes in formatting are not important in terms of change management.

There’s another variant out there that’s got some traction: The standard FSF/GCC programming style.

In this style, subsequent indentations are in multiples of four spaces. And then any sequences of eight spaces are replaced by tabs. Thus, what you get is:

…for (foo) {

  • bar;
  • for (baz) {
  • …froboz;
  • }

where - is a tab and … is four spaces.