Keep tabs as tabs or tabs as spaces

[R Erasmus]

At our company and part of our coding standard, no tabs aloud and there is a good reason for it too. Opening files that uses tabs in different editors can create a mess of things. We use 2 space intentation only which limit the backspace to only 2 presses. And then there is always which eliminates the 2 backspaces. Use tab as long as your editor automatically converts tabs to spaces I'll recommend.

"Program testing can be used to show the presence of bugs, but never to show their absence." << please vote!! >>

[code_junkie]

Tabs for indenting, spaces everywhere else! :thumbsup:

[S Houghtelin]

We recently went through a rewrite of our software standards and the company now mandates spaces over tabs. The reason for this is that every coder has their preferences, tabs, spaces, tabs whatever. We use several different IDEs and compilers with their respective editors for each microprocessor platform we use but we have a common algorithm that we use for our products. What looks aesthetically nice in one editor looks like crap in another. This can make it difficult when the spacing is different or a particular editor does not have the ignore whitespace function when comparing code. Then there’s the version control software and viewers, and so on. Most of the editors allow you to choose between spaces or tabs when using the tab key but will not convert the tabs to spaces when viewing code. So for me it’s not a matter of preference, I have to use spaces, but I have to admit, it is nice when the code indentation matches the rest of the code regardless of what I am using to view the code. And makes the compares easier to go though during V&V :zzz: .

It was broke, so I fixed it.

[Peter Mulholland]

Ennis Ray Lynch, Jr. wrote:

VS defaults to spaces so why change it.

Really? I've always been under the impression that the default in VS is tabs, at least I've always had to go into the options to check the 'replace tabd with spaces' option.

Ennis Ray Lynch, Jr. wrote:

It is the efficient vs. the lazy in this argument. Most people are too lazy to change the flow

I think my previous comment debunks this idea.

Ennis Ray Lynch, Jr. wrote:

Watch the people who are in favor of coding with spaces actually code. Watch how slow they (usually) work

how do you think replacing tabs with spaces actually slows down coding? I just don't get this one.

Ennis Ray Lynch, Jr. wrote:

Yes it matters. There is nothing worse than having to break away from the keyboard to use the mouse.

Again, why would using spaces require us to resort to the mouse more often? The Ctrl key is pretty damn handy for navigating through code.

Pete

[Peter Mulholland]

Ben Barreth wrote:

If I select multiple lines and hit tab, it indents it all.

And with 'replace tabs with spaces' this will also work and replace all tabs with spaces, I use it regulary to 'correct' tabs to spaces in editors where I don't trust the 'nicify code' function.

Pete

[Andre vd Wal]

As a rule at our company we convert all tabs to spaces. This is to stay consistent throughout the code base and it also helps when it comes to merging branches in your source control system.

[P0110X]

I prefer tabs and I use to tab the document, so the source code control tool "ignores" the spacing pain

_class MySignature _{ __public override void toString() __{ ____return "hi ;)"; __} _}

[Stefan_Lang]

Rob Philpott wrote:

Or worse yet - "does it matter?"

If you want a hard answer, the answer is that most probably it does matter. Or, more to the point: if you know for sure that every tool you use to view, edit or in other way work with your source code files uses the same tab width, and every other developer working on the same files, and any other person who for some reason works with your files, only will use tools with that same tab width, then you're safe to use and store only tabs. Unfortunately, in 99% of all cases the above conditions are not met, and so you're 'safer' to store tabs as spaces instead. Having to backspace for formatting purposes - repeatedly or not - is something you shouldn't need to do at all - either you have specific functions to increase and decrease text indention, or your editor is smart enough to interpret a backspace at the start of a the text in a line as a command to decrease the indention (I've worked with such an editor once, but unfortunately can't remember it's name). Here are some examples on how stuff can get messed up by storing tabs instead of spaces: 1. Code comments appear unaligned because of different tab settings 2. Various developers see different indentions on different lines, because the tools they use insert formatting in different ways, including, possibly, spaces for indentions 3. Viewing changes becomes confusing because tabs and spaces might be considered different by the diff tool, even though the code itself is unchanged. Also alignment issues may arise from different tab settings for the viewer 4. Edit functions that cut/copy vertically blocks of text (only rectangular areas rather than whole lines) might not work properly when using tabs (ok, not many editors support that, and there is a very limited use for that functionality, but still...) Fortunately, most tools like editors and viewers can be set to use a distinct tab width, so if you feel more comfortable storing tabs, then just make sure that everyone does this and configures all their tools to use the right tab width. Then you're good to go. :) Unfortunately there's always someone who stores tabs as spaces ... ;P Personally, I do always store spaces, because this is the only way to make sure that everyone will see the indentations exactly as I made them. :cool:

[Roland van der Plas]

I also agree. Referring to rule #9 of Elements of C# Style: Do not use "hard" tabs. I guess it's a rule for other languages as well..

[GenJerDan]

Yep, tabs are all well and good*, but too varied in size. I often open up a source in Notepad to check something and tabs send the text waaay out there to the right at times. *Any R. Stevie Moore fans here? :-D

[Stefan_Lang]

This is exactly what I have been thinking of. Just didn't bother to mention it, because it reminds me of at least three occasions I've seen a tool like Notepad++ being suggested as a 'must-have' replacement for this hopelessly outdated piece of nostalgic-ware. ;)

[jsc42]

Visual Studio? Use Notepad (for Windows), vi (for Unix / Linux), ISPF or TSO EDIT (for MVS), or EDIT or EDLIN or COPY CON: for MS-DOS. I always used to use 3 spaces with punched card and paper tape. I now use Tabs at the start of lines, after the command keyword and before '='; and single space everywhere else. It maximises visual layout whilst minimising storage / network bandwidth.

[Gary Wheeler]

:^)

Software Zen: delete this;

[patbob]

Tabs or spaces doesn't matter, as long as A) everybody agrees how many spaces a tab is equivanat to, and B) preferably everybody uses spaces or everybody uses tabs, not a mixture of some using one and others using another. Some external tools have assumptions built in too. The only violation to this should always be old code. Whatever it was done as, do any new changes in the same indentation style, even if it isn't your religion. Where I work, we do none of the above and our code's a total mess. Every developer has their religion and nobody's got the authority to dicipline the others, so nobody can decree a standard. Crtl-K crtl-F is my friend :)

patbob

[TripShock]

I always use tabs with a tab width of 4. What I would be interested in knowing is, why is there even an option to use spaces instead of the tab character? Doesn't tab deserve the right to exist by itself? Who introduced this idea of converting all your tabs into spaces and why?

[LintMan]

Tabs are pure evil. Well, OK maybe not, but I hate them. Part of the problem is that different editors and tools treat the tab character differently. Some always use 4 chars, some use 8, some indent to specific column numbers, some use a user-selected number of spaces. If everything is tabbed and you use a single set of consistent tools, that's no problem. The problem is when spaces and tabs get mixed together and/or you need to work in a heterogenous environment things get ugly really quickly. The basic fact is that you can't trust tabbed text to look the same and be lined up the same from one computer setup to the next. And if you mix in someone using spaces, things go really screwey when someone else opens the file with a different tab behavior and suddenly the spaced line is out of whack through nobody's fault. (And please don't tell me that every code line MUST begin with a tab like it's a make file or something). None of that happens if everyone uses spaces. Then the text is formatted the same regardless of what editor/tool/platform/etc you use. This benefit far outweights the "symmetry" of a backspace removing 4 spaces at once. Particularly when most good code editors can unindent you automatically regardless of tabs.

[Fulvio Dominici]

REAL tabs are the one and only thing to use, spaces must appear one at a time. And, with a tool you can change tabs in spaces, but not the other way around. :cool:

[Frank Peelo]

Spaces always. Tabs are 8 chars, or 4 chars, or 3 chars, or something else depending on the phase of the moon. They are *meant* to be configurable, and your indentation is probably not. Just because some printers in the 1980s had fixed tab width doesn't mean you can rely on it. And if you are working with a variety of people and/or tools, sooner or later you'll get your code back with the wrong tab size and give yourself pain. Use spaces and then everyone knows where you're indented.

[Frank Peelo]

Because tabs predate high-level programming languages. On a typewriter, you can set the tabs to get text to line up, BUT the big thing about them is that a tab could be one level on one page, another level when you go to type in a different column of names, or whatever. And when you go to type the next document, you could set different tab sizes. Go to a different typewriter - you are certainly not continuing the same document, so you will have different tab settings again. Look at tabs in a word processor - that's the sort of thing they are for. In a programming language, you want your levels of code to be indented by a certain amount, which you do not want to change half way down the file, or when you go to a different PC. And tabs are just the wrong tool for that. Spaces (in a monospaced font, and that's the only type to use when programming) have the same width as any other character. Always. And that's what you want when indenting. The tab key should indent by the amount you want, and the backspace (or typing a } ) should outdent you by the same amount. But that's interpreted by the editor, not by whatever is converting your source code into a displayable format -- which might be an editor, or it might be someone else's editor, or maybe a printer if you're being retro. So the editor should do what the keys you press tell it to do, and record the result unambiguously in your source code file. And "unambiguously" means with spaces. Recording a tab character in the source code means that what you type will be reinterpreted by the editor that is loading it, and the way it is reinterpreted may not be what you intended.

[RobEpworth]

It matters big time... Anyone using Source Control needs to consider the implications, in particular when working on multi-developer projects. Source Control (most of them) only store the delta (changes) of the code. Now this setting is a personal preference, so each IDE can set not only how many spaces = 1 tab, but also if it should convert one to the other. (how it handles quoted strings is another story) As devs checkout code, don't like the formatting, change it, and check it back in. You end up with source deltas that contain nothing but tab to space and space to tab conversions - and possibly 1 or 2 real code changes. (and it all has to be stored somewhere) This becomes more problematical when it comes to merging code branches. Tab/Space conversions often upset the offsets used in deltas which results in a merge requiring manual intervention to correct conflicts. I don't care which one you use individually, but if you're working on a group project EVERYONE needs to be using the same settings.