I used to use TABS in all my files.

But now I decided to use spaces.

I want to remove all tabs.  I will probably work on a Clojure program to remove tabs from a file over the next few weeks.

Do you guys use tabs or spaces?

spaces.  and why write a program.  Emacs.

I'd use spaces if my boss allowed them.

Tabs suck because I use many different programs to see or edit code. Each program has its own setting for tab width, and whether to insert spaces or a tab when you hit the tab key.

spaces.

tabs should be banned unless it's a flat text database file where it is separating records that don't permit tabs

The tab key on the keyboard is for the purpose of advancing the cursor to the next tab stop, not for inserting tab "characters".

spaces

http://www.jwz.org/doc/tabs-vs-spaces.html

I had to change my name.

http://www.crazyontap.com/topic.php?TopicId=47655#573987

"I'd use spaces if my boss allowed them. "

Yikes. Your boss must be a software retard.

Tabs, because different team members have different preferred indent sizes, and this lets us set VS.NET to our individual liking.

My boss is anything but a retard.  But he is a control freak.

I'm on a mission to assassinate anyone who puts tab characters in source files. After I have assassinated enough people, all tab characters will be eliminated!

I would like to subscribe to your newsletter.

Look up 'expand', which is probably part of cygwin or linux (Mac OS X has it). Something like, I dunno, "expand $( find . -name '*.c' -or -name '*.h' $)" will get you a large part of the way. If you're more a DOS sort of guy then this will be a bit more annoying to do quickly though.

Interestingly 'unexpand' (expand's opposite) will do what text editors SHOULD do, which is to use tabs to indent and then use spaces thereafter. Result: in general, tab width changes alignment of code, but doesn't mess with any white space inside the lines. So tabular data, vertically-aligned code and diagrams in comments are all preserved.

This isn't an option that I've ever seen advertised very well in any of the text editors I've used, which is a shame, because the poor old tab character, if used like that, could actually be genuinely useful.

"Tabs suck because I use many different programs to see or edit code. Each program has its own setting for tab width, and whether to insert spaces or a tab when you hit the tab key."

Spaces blow because every programmer wants to use their own random number of spaces for tab expansion.

If you use tabs, programmers can use whatever crappy expansion they like and it doesn't change the code in random/crappy ways (source code diffs due to different tab expansion is stupid).

"Tabs suck because I use many different programs to see or edit code. Each program has its own setting for tab width, and whether to insert spaces or a tab when you hit the tab key."

This is because you are too stupid to know how to change software configuration. It's bizarre that professionals have problems doing this.

No, tabs suck because every different editor every different programmer uses expands them differently -- two spaces/tab, 8-spaces per tab -- it means any lining-up formatting one person does using tabs is fubar'ed if that file isn't opened with EXACTLY the right tab setting.

Not to mention, if TWO programmers have worked on the same file, with different tab settings, it becomes impossible to select a tab-setting which isn't fubar'ed.

That's why unexpand does the right thing, almost. Tabs for indentation, spaces thereafter. Unfortunately, going by the man page, since it doesn't know the right indent level it just tabifies all leading spaces. If the leading white space is part indentation and part lining things up you're stuffed. For tabular data and lining up variable declarations and whatnot it should be fine though!

I might try to work out how to get emacs to do this properly, though the maintainers are probably anti-tab nazis and will have gone out of their way to make things difficult.

>> No, tabs suck because every different editor every different programmer uses expands them differently <<

Get better tools.  Ones that let you set your expansion level.

And tabs are an advantage where having multiple programmers working on the same code is concerned.  Plus the diff utility doesn't flag the entire file as "changed" afterwards.

If you start out using spaces and everyone continues to use spaces, 'diff' doesn't complain about converted tabs then either.

"If you start out using spaces and everyone continues to use spaces, 'diff' doesn't complain about converted tabs then either."

No, because some programmers use 2 spaces or 4 spaces.

I ran across a small (20 line) piece of code with 4-5 different spacing conventions in it.

"No, tabs suck because every different editor every different programmer uses expands them differently -- two spaces/tab, 8-spaces per tab -- it means any lining-up formatting one person does using tabs is fubar'ed if that file isn't opened with EXACTLY the right tab setting."

Different programmers expands them differently. Explain how using spaces changes that? And each different expansion becomes a permament change in the file and permanently "fubar'ed".

And this is actually not as much of a problem as you indicate.

"Not to mention, if TWO programmers have worked on the same file, with different tab settings, it becomes impossible to select a tab-setting which isn't fubar'ed."

Unless the programmer is use a really-wacky indentation style, this is much less of a problem than you think. And it is WORSE with spaces!!

============

Anyway, files in multi-person projects should be run through a "pretty-printer" to make things consistent.

I think you're missing the point about the diff tool.

If a programmer (who uses spaces) reformats a file to fit their indention mode, the diff tool will flag every changed line as being "different"

Same way with a pretty-printer.  Every line it changes is now "different", even if it was semantically the same before/after.

You need a way to represent an indent that stays the same from programmer to programmer, no matter what it's visual representation.  And tabs fit that bill.

Nah, tabs simply let you defer the decision -- like using a "pretty-printer" program.  The REAL problem is that people haven't YET settled on a consistent way of formatting code. 

This being such a basic thing, you might assume it would have happened before now.  And it HAS happened -- why there's about three or four different (incompatible) ways of formatting C/C++ code.  It's the incompatibility that's the problem.

Shoot, we haven't even got away from the idea that code can be "self-documenting".

Meh.  I conclude this is an unresolveable problem, agree to disagree, and let it go.

Yeah, discussions about the one-true-brace style are orthogonal to tabs vs. spaces.

"Nah, tabs simply let you defer the decision -- like using a "pretty-printer" program.  The REAL problem is that people haven't YET settled on a consistent way of formatting code."

There are differnces in formatting but using spaces makes those problems worse rather than better.

xample "If a programmer (who uses spaces) reformats a file to fit their indention mode, the diff tool will flag every changed line as being 'different'".

Using tabs allows each programmer to use whatever goofy indentation they like without these diff problems.

xample "Same way with a pretty-printer.  Every line it changes is now "different", even if it was semantically the same before/after."

One would have to use the pretty-printer to establish a base-line for the format. Then, one would use a pretty-printer to fix up the format before any check-ins. The value of a pretty-printer is that it allows one style to be applied to shared code and reduce arguments about what format style to use. It also avoids the problem of programmers ignoring the existing style and using whatever style they like.

"This being such a basic thing, you might assume it would have happened before now.  And it HAS happened -- why there's about three or four different (incompatible) ways of formatting C/C++ code.  It's the incompatibility that's the problem."

Most of the problems relating to formatting differences are in embedded data and with people working too hard to keep line lengths too short.

Other differences in formatting are not really related to "logical" indenting and hold up quite well using tabs. Nothing holds up to using spaces unless people all can agree to using the same number of spaces.

"unless all people can agree to using the same number of spaces" -- well, yes, I was thinking that went without saying.  Or at least being willing not to screw with another person's formatting by adding or taking away spaces.  AND putting the open-close-curlies in the same places, without which how many tabs/spaces you use can be irrelevant.

And I don't know where YOU work, but where *I* work "putting something through the pretty printer as a last step" would be resisted like mad.  Why do you THINK everyone wants to format their code differently?  Because they cannot (and will not) agree on the format it should have! 

A pretty-printer will FORCE a format on the code -- but that's just what the programmers are resisting in the first place.

Sounds like you and I have come to the same place -- I want people to use spaces, and get a fixed format.  You want to use a pretty-printer to get the same thing.  We're both doomed.

"And I don't know where YOU work, but where *I* work "putting something through the pretty printer as a last step" would be resisted like mad.  Why do you THINK everyone wants to format their code differently?  Because they cannot (and will not) agree on the format it should have!"

People resist this because the policy is to let them do whatever they want.

The key question is whether or not a consistent format is valuable. If it is valuable, then people have to give up on arguing about differences. If it isn't valuable, then arguing about spaces versus tabs is stupid. Let people do whatever they want and quit complaining about tabs.

===========

"A pretty-printer will FORCE a format on the code -- but that's just what the programmers are resisting in the first place."

The point of the pretty-printer IS to force the format. One either has one format (that has to be forced) or a whole-bunch of them. The value of the pretty-printer is that it is not a person (really) doing the forcing.

===========

"Sounds like you and I have come to the same place -- I want people to use spaces, and get a fixed format.  You want to use a pretty-printer to get the same thing.  We're both doomed."

No, spaces are stupid. Why force people to use a standard number of spaces if it's unnecessary? If you use tabs, people can choose to use whatever expansion they like.  It's petty to force people to use a particular number of spaces when software easily lets people do what they want.

It's not like using real tabs is forcing people to behave differently (they use the tab key whether or not the tabs are expanded into spaces).

"Sounds like you and I have come to the same place -- I want people to use spaces, and get a fixed format.  You want to use a pretty-printer to get the same thing.  We're both doomed."

No, you are stuck endlessly arguing with people about spaces and still dealing with them ignoring you if they don't like your weird preference.

The pretty-printer does more than just dealing with spaces. It also forces the format without having to argue with people.  And arguing is a waste of time because you'll never get people to agree to one format. You also will have to restart the argument with every new group member.

Using a pretty-printer makes it easier to keep from endlessly arguing about this crap. Again, if you want a consistent style, you have to pick one. Once you pick one, you have to enforce it. Yelling at people who do not follow the format is stupid. A pretty-printer automates the enforcement.

We're not yelling at people.  We're allowing freedom.  I'm just trying to explain why I like spaces over tabs.  No big deal.

But I find it ironic you're ENFORCING a style using a pretty-printer (by the way, do they ALWAYS work?  With C Macro's?  Static string arrays?  Initialized static string arrays?  What do they do, "parse" the code to set the indents?  And how do they resolve the open-curly/close-curly placement debate?)

It would be nice if automated solutions had no bugs -- perhaps you're on the right track here.

But what I said before stands -- the HARD part is getting agreement on a coding style.  How you ENFORCE that coding style is a fairly simple implementation detail, compared to getting that agreement in the first place.

"We're not yelling at people.  We're allowing freedom.  I'm just trying to explain why I like spaces over tabs.  No big deal."

Choose: freedom or consistancy.

You are not advocating "freedom". You are complaining about inconsistancies (see following). If you were "allowing freedom", you would not complain about inconsistancies!

"Not to mention, if TWO programmers have worked on the same file, with different tab settings, it becomes impossible to select a tab-setting which isn't fubar'ed."

This issue, of course, is much worse with spaces. If you "allow freedom", then people are free to choose whatever number of spaces they want. The reason tabs make sense and spaces don't is that tabs allow people to be "free" without screwing up other people.

Anyway, the "freedom" argument in a group is asinine. People in a company should be writing code that helps other people deal with it (eg, maintain/enhance it). It's software engineering not "painting".

It is key for people to realize that they are writing code for other people.

===============

"But I find it ironic you're ENFORCING a style using a pretty-printer (by the way, do they ALWAYS work?  With C Macro's?  Static string arrays?  Initialized static string arrays?

There is no "irony" (you don't appear to understand the word). Using a consistent style requires deciding on a particular style and that decision is never going to be acceptible to everybody.

If you want a consistant/standard style, you have to enforce it.

Since formatting issues are never resolved, choosing a standard is somewhat arbitrary. There are a few places (eg, data) where pretty-printers (I use "indent") don't do things the way I'd prefer. For code, it works very well.

"What do they do, "parse" the code to set the indents?"

Yes, in a very basic way.

===============

"And how do they resolve the open-curly/close-curly placement debate?)"

If you are "allowing freedom", there is no debate!

They resolve the pointless "debate" by eliminating the debate (pretty-printers can be configured to do one or the other.)

(By the way, the brace at the end was K&R way of reducing whitespace/pages in a printed book. They never advocated that style as being "better". There are other things that K&R did in their book that would not be acceptible practice for professional programmers.) People choose the brace-at-the-end style because that is what they are used to, not because it is "better". (It actually makes finding mismatched braces harder.)

Anyway, the brace-at-the-end appears to be much less popular than the brace (or its equivalent) on a new line. And if a brace-at-the-end programmer can't deal with new-line braces, then that programmer is deeply incompetent.

One value of the pretty-printer is that, if a programmer uses the wrong style, the pretty-printer automatically corrects it without any arguments! Non-antisocial programmers will also tend to adopt their style to the prevailing style.

===============

"It would be nice if automated solutions had no bugs -- perhaps you're on the right track here."

Any particular formatting style has "bugs".

===============

"But what I said before stands -- the HARD part is getting agreement on a coding style."

It isn't "hard" to get agreement. It's impossible. The goal isn't to get agreement. The goal is to get a consistent style.

"How you ENFORCE that coding style is a fairly simple implementation detail, compared to getting that agreement in the first place."

No, getting agreement is stupid because it is impossible. The real goal is a reasonable standard.

Interesting.  So you're going to get a "consistent style", without anyone agreeing to it?

I think this is one of the reasons this hasn't happened yet.

"Interesting.  So you're going to get a "consistent style", without anyone agreeing to it?

I think this is one of the reasons this hasn't happened yet."

Groups have managers/bosses/processes, don't they?

If people are working with a group or in a company, there are often things that they are required to do that they don't agree with.

The pretty-printer doesn't exactly require to change the style they use.

Do you think there is a value in having a shared-code base (one that is contributed-to and maintained by a group) be in a consistent style? Or, is it OK to have many different styles be present even in the same "page" of code?

If new group members can't make minor adaptations to their coding format, then then aren't likely to be good at writing code for the group (ie, other people). Again, people write code for other people. Doing that well is part of the job.

==============

In my experience, one doesn't even need 100% consistancy as long as the major/important things (tabs, standard/normal indentation, braces) are consistant.

One reason braces-at-the-end is bad is that it results in annoying left/right scrolling when using tools to match braces. It also allows variable line-lengths to obscure the general program structure.

Getting a group to use a single/consistant style is no more difficult that getting them to use one source control system. Programmers who are overly whiny about their preferred style are bad programmers.