Elastic Tabstops — An End to Tabs vs. Spaces?

An anonymous reader writes "Along with Vi versus Emacs, the tabs versus spaces argument must rank as one of the classic holy wars among coders. Here's an attempt to solve it by making tabstops expand or shrink to fit their contents. The concept's pretty cool to use, so be sure to have a play with the demo!"

Comments

A standard tab length would be easier

[linvir]

I think this is the wrong kind of solution to the problem. A standard would be easier. Just have someone say "Tabs are now officially SOME_NUMBER spaces long, so fuck you." Get Linus to approve of it or something for good measure.

Speaking of tabs, something that I would absolutely love:
I want to be able to indent or unindent the opening statement for a given loop, be it int, sub, function, if, for or else, and have the entire section that it describes, including the braces, indent accordingly.
Anyone know of an editor that has this?

Re:A standard tab length would be easier

[rcamera]

I want to be able to indent or unindent the opening statement for a given loop, be it int, sub, function, if, for or else, and have the entire section that it describes, including the braces, indent accordingly. Anyone know of an editor that has this?

both vim and emacs will do this. unless i misread the question...

Re:A standard tab length would be easier

[Bodhidharma]

Eclipse does that.

I don't know what the big deal is, just :set ts=4

Re:A standard tab length would be easier

[Amouth]

I vote for TAB = 4(four) Spaces

Re:A standard tab length would be easier

[tickbox]

in vim: ctrl+v and select your area, shift+i,tab,escape

Re:A standard tab length would be easier

[Jeremi]

I think this is the wrong kind of solution to the problem. A standard would be easier. Just have someone say "Tabs are now officially SOME_NUMBER spaces long, so fuck you."

You might as well tell the world "Earth's official language is now officially Esperanto, so fuck you". The effect would be about the same.

Re:A standard tab length would be easier

[tickbox]

nm...think i misinterpreted the question

Re:A standard tab length would be easier

[Anonymous Coward]

Especially if you say it in English and finish with an expletive...

Re:A standard tab length would be easier

[Anonymous Coward]

I must have missed the part of the discussion where tabs/spacing became intimately interwoven into human culture and society.

But even beside that, a lot of things are set semi-arbitrarily in the tech world. So why not the length of a tab?

Re:A standard tab length would be easier

[Anonymous Coward]

I vote TAB = 2(two) SPACES.

Re:A standard tab length would be easier

[Anonymous Coward]

Linus says "tabs are 8 spaces, fuck you"

He's been saying that for a while.

Re:A standard tab length would be easier

[Pheersome]

In vi or vim, put the cursor on the opening brace and type '>%' (that's to indent; type '<%' to exdent).

Re:A standard tab length would be easier

[linvir]

I move that we temporarily adjourn proceedings and reconvene on Thursday of next week, for the dupe.

Re:A standard tab length would be easier

[Jeremi]

I must have missed the part of the discussion where tabs/spacing became intimately interwoven into human culture and society.

They became interwoven into the computer-programming subset of society back in the 60's and 70's, if not earlier.

But even beside that, a lot of things are set semi-arbitrarily in the tech world. So why not the length of a tab?

Because the proposal isn't to define a new standard, it's to re-define a very well-entrenched (if crappy) existing standard. All 60 million people who are already happily accustomed to doing things the old way will simply ignore the new "standard", and a standard which nobody uses is worthless.

Re:A standard tab length would be easier

[Daniel_Staal]

Actually, it is attempts to do that which have created the current confusion. Some were obviously too long, some obviously too short, and the end result is tabs which aren't useful.

I actually like this idea, because it actually you from using this seemingly-simple but in actuality horribly complicated idea that tab = x*space. Instead they have an actually simple idea: Each tab is a seperate column of text. Line up items in the same column with each other. (Of course, how simple this is in practice is yet to be deterimined, but it seems simpler to me.)

This idea is actually about seperateing sementic and content info. Programmers use tabs (those who do) to convey sementic info. If we can make the program understand that, then we can offer more flexiblity to the user on how to present the information.

Re:A standard tab length would be easier

[linvir]

Indeed, screw this. I'll just stick with the PEAR standard of four spaces per indent, no tabs.

Re:A standard tab length would be easier

[aymanh]

I want to be able to indent or unindent the opening statement for a given loop, be it int, sub, function, if, for or else, and have the entire section that it describes, including the braces, indent accordingly.

In Vim: Press shift+v to highlight the current line, go to the opening brace, press % to go to the closing brace (highlighting the whole block in turn), then press = to auto-indent.

In command mode, == auto-indents the current line, << and >> indent to right and left respectively.

Back to the original article, I have the following in my .vimrc:

set et
set sw=2
set sts=2
set smarttab

These options replace tabs with 2 spaces when pressing the tab key, indenting, and auto-indenting.

Re:A standard tab length would be easier

[GroeFaZ]

Anyone know of an editor that has this?

If you want that from an IDE, eclipse does that, and pretty robustly at that. I wouldn't want to miss it.

For more simple editors for a quick text edit, my favorite is EditPlus. It lets you choose between classical tabs and whitespace tabs, as how long (in characters) a tab in either mode should be treated, it has the auto-indent you mentioned, reacting to freely definable characters (for example, auto-indent forward after '{' or '(', and back after '}' or ')', respectively). Best of all, it lets you define these parameters independently for plain text, c/c++, java, HTML, Perl, etc., etc., as well as any number of custom syntaxes you may wish to import or define yourself. A small selection of useful features of a great tool. Disclaimer: I am in no way affiliated with Editplus or the company behind it, just a happy user.

Re:A standard tab length would be easier

[andy314159pi]

I think you're on to something. Some regulatory body or Linus should redefine the tab length permanently. It's silly to have system dependent or editor dependent definitions of tabs.
And things like this are standardized all of the time in committees to pretty good effect. For instance, whatever language you code in was probably standardized by a committee that just claimed authority over the language and was granted it de facto by the compiler writers.

Re:A standard tab length would be easier

[Phreakiture]

You might as well tell the world "Earth's official language is now officially Esperanto, so fuck you". The effect would be about the same.

La lingvo oficiala da tero estas Esperanton, tial fiku vin!

Re:A standard tab length would be easier

[kevlarman]

i was about to comment on how key combinations like that are why i use emacs, then i realize...
C-Space C-c } Tab

Re:A standard tab length would be easier

[kevlarman]

oops, i meant C-\ not tab

Re:A standard tab length would be easier

[tfried]

> Anyone know of an editor that has this?

I believe kwrite/kate is still missing from the already long list of editors which have that feature. Usage instructions: Ctrl+I indents the current line/selection. To extend to a full loop / section, either select the section manually, or use the code folding feature and select just that one line before pressing Ctrl+I. Ctrl+Shift+I to unindent.

Re:A standard tab length would be easier

[linvir]

Tabs versus Spaces: An Eternal Holy War.
Jamie Zawinski

My opinion is that the best way to solve the technical issues is to mandate that the ASCII #9 TAB character never appear in disk files: program your editor to expand TABs to an appropriate number of spaces before writing the lines to disk. That simplifies matters greatly, by separating the technical issues of #2 and #3 from the religious issue of #1

A very clever solution indeed. Apparently some clever bastard sovled this issue six years ago. Return to your homes. Nothing left to see here.

Re:A standard tab length would be easier

[Rinisari]

La lingvo oficiala de terglobo estas non oficiale esperanton, do fiku vin!
Are you happy? / Cxu vi estas felicxa?

Silly Slashdot and its lack of UTF-8 support ;-)

Re:A standard tab length would be easier

[cagle_.25]

Mod grandparent funny and parent even funnier. :-)

Re:A standard tab length would be easier

[GroeFaZ]

How can you tell whether nobody will use a new standard if it is significantly better than the old one? If you admit the old standard is crappy, why not even try for the better? Considering how tabs tend to break across platforms or even across applications, it already seems like everyone is doing what he wants anyway. Doing or not doing things because "that's the way it used to be and we don't want change because change is hard" just doesn't make sense, especially considering the fact that we're talking about computers. That's not exactly a field whose methods are carved into proverbial stone like, I don't know, metal smithing, pottery, or something ancient like that.

Re:A standard tab length would be easier

[eosp]

But neither of them have a mode where keystrokes correspond to keywords.

Wouldn't it be nice to type:

#i<stdio.h>

imain(nArgs,pszArgs){printf("Hello, World!\n");r0;}

and get the full Hello World program, with variables correct based on prefix and everything else working as it should?

Re:A standard tab length would be easier

[doshell]

La lingvo oficiala da tero estas Esperanton, tial fiku vin!

Mi pensas, cxu "fikugxi" ne estas pli tawga vorto? :P

Saluton, karaj esperantistoj!

Re:A standard tab length would be easier

[Anonymous Coward]

Score: -1, Gibberish

Re:A standard tab length would be easier

[x2A]

Me too!(too)

My coding style is that a single function can go several levels/indents deep, too wide a tab space can really start eating up screen space.

Re:A standard tab length would be easier

[x2A]

I think we need to decide what refreshments will be available on the thursday. I vote that we're at least allowed 3(three) sausages if we choose the sausages 'n mash option, 2(two) just isn't enough.

Re:A standard tab length would be easier

[Anonymous Coward]

"All 60 million people who are already happily accustomed to doing things the old way will simply ignore the new "standard", and a standard which nobody uses is worthless."

Which old way would that be? Hard tabs or soft tabs? 2, 4, 8 or X spaces wide. How about a mix of hard tabs and spaces?

The way I see it he's proposing a new way of doing things - take it or leave it. It does seem to better than any of the existing methods though!

Re:A standard tab length would be easier

[Anonymous Coward]

Great. Now how am I suposed to create makefiles?

Re:A standard tab length would be easier

[Phreakiture]

Mi pensas, cxu "fikugxi" ne estas pli tawga vorto? :P

Jes, sed "fikugxu"? Mi ne scias. Posible "fikugxegacxu"? :-)

That last one makes me want to say "Gesundheit" (try saying it out loud).

Re:A standard tab length would be easier

[peterpi]

I can't understand why people still find this a problem. It's so simple. Tabs indent, spaces line up. In other words

• space means "move to the right by exactly one character width"
  
• tab means "I want to indent, move across a bit". "A bit", and "across" mean whatever you like. It could be right8 chars, right 4 chars, left 2 chars, down 947565 chars, whatever you like. That's the beauty of it; everybody gets to view it in their favourite format.
  

It's so simple, it's quite embarassing for the whole of the computer-literate society that people still get their kickers in a twist about it.

Anybody who tries to lay down the law by saying that a tab must be 4, 8 or 2 characters' width has missed the point of the tab key completely.

As for your wish, I'm willing to bet money that either vim or emacs will do it for you.

Re:A standard tab length would be easier

[Intron]

So far as I know, "tab" has always meant "Advance the carriage to the next tab stop" and has never meant "advance a fixed number of spaces". The default tab stop setting varies from program to program. In Word its on 1/2" boundaries, and in most editors its on 8-character boundaries.

Re:A standard tab length would be easier

[peterpi]

I vote for TAB = however many spaces you want it to be. If you meant "move to the right by the width of four characters", press the space bar four times.

Re:A standard tab length would be easier

[TeknoHog]

This idea is actually about seperateing sementic and content info. Programmers use tabs (those who do) to convey sementic info. If we can make the program understand that, then we can offer more flexiblity to the user on how to present the information.

Yeah, imagine a language that doesn't need braces because tabs already contain the same semantic (sic) information.

Re:A standard tab length would be easier

[peterpi]

You might as well try and define what the 'end' key does. Or better still, define what the F7 key does.

Tab is already standardized. It means either "move onto the next record" in tabular data, or in programming languages "indent". If you have a preference for how much like code to be indented, then you get to set your editor in accordance. Indenting code with tabs is far more considerate than indenting with spaces. Indenting with tabs says "Indent a little. I trust you to set your editor accordingly". Indenting with 4 strikes of the space bar says "In my opinion, four spaces, not two, nor eight, nor six, is the only way to indent. If you want to read my code you shall accept my rules".

Re:A standard tab length would be easier

[plalonde2]

Not at all. At least vi's syntax for this is noun-verb setup: the > says to indent, and can be followed by any range specifier - % happens to jump matching brace pairs. You could as well have said %6j to indent the next 6 lines.

Re:A standard tab length would be easier

[linvir]

I'm sure a lot of things seem so simple when you're so ignorant of the actual issue.

Why does the PEAR coding standard insist on space-only indentation?
Using spaces and avoiding tabs is the only way to ensure that a piece of code is rendered consistently in all editors and viewers. Many editors render tabs as 4 spaces, and a lot of editors, terminal programs and utilities render tabs as 8 spaces.

Re:A standard tab length would be easier

[Anonymous Coward]

How can you tell whether nobody will use a new standard if it is significantly better than the old one?

So do it. Announce your new standard and see who cares. If you don't feel official enough then give yourself a name "International Committee for Tab Standards" or something, set up a pretty web page and send out a few press releases. Nobody will care.

Re:A standard tab length would be easier

[Goyuix]

I honestly don't see this as a problem (though certainly recognize that some people view it as such). My personal belief is a TAB should be a TAB and a SPACE should be a SPACE. If your organization (which might be an OS foundation, corporation, class at school, yourself, whatever...) recommends/enforces style guidelines, let the group dictate.

Also, if it is a big concern, make use of sed to standardize the code (as best as possible) and then use it again to convert back and forth. It is available for win32 as well you know http://unxutils.sourceforge.net/

Oh, and one last note: A good editor will let you set the tab length in the display. I did like in the demo JAR how the comment lengths would stay (right) aligned (mostly) - which would be a very nice feature to toggle on/off in an editor as well.

Re:A standard tab length would be easier

[EsbenMoseHansen]

Emacs can do all that. The only drawback is that you have to use Emacs :) ccmode and a abbrmode, I think.

Re:A standard tab length would be easier

[jonadab]

> I think this is the wrong kind of solution to the problem. A standard would be easier.

Clearly you are not familiar with the tabs-vs-spaces argument.

Advocates of tabs say that having everything indended by multiples of some standard
amount is a good thing.  This is, of course, wrong for source code in many computer
languages, because it prevents things from being indented to the correct position
relative to the line above, as in the following example (in the Inform language)...

Object matchbox kitchen_cupboard
class cardboard,
  with short_name "matchbox",
       description "A standard cardboard matchbox.
                    It says ~Strike on Box~ on the side.",
       name 'matchbox' 'box',
   has openable container;

I suppose it doesn't matter for write-once applications, but if you're trying
to write _maintainable_ code, it's essential to have things line up properly,
and that means they often need to line up under specific characters on the line
above.  That's possible with tabs if the character they need to line up under is
preceded by whitespace (as it generally is with e.g. SQL), but if that's not so,
tabs are useless.  I don't see how these new "expanding" tabs change that.

Inform is the *best* example I know of a language that *cannot* be properly
indented with only tabs, i.e., spaces are *needed*.  There are other languages
with which this is somewhat true, e.g. Lisp (wherein you often want to line up
under a specific open-parenthesis which may not be preceded by whitespace)
and Perl (although most Perl code is not indented as well as it could be,
partly because tools such as cperl-mode do not support it).

If you agree on a fixed width for tabs (e.g., 8 characters), you could use a
mixture of tabs and spaces, but that won't make tab-indentation advocates happy,
because they want to get *rid* of leading spaces and use tabs only, usually
because they want to use proportional fonts.  If you're going to use spaces
for indentation, you might as well use all spaces and no tabs.

Re:A standard tab length would be easier

[iced_773]

I vote for this to be the next Slashdot poll.

Re:A standard tab length would be easier

[bheer]

Linus is already on record saying that tabs == 8 spaces. However (and sorry to burst your bubble) Linus isn't God. He isn't even Moses.

8 spaces makes very little sense for some environments, especially this newfangled web programming thingy all the cool kids are doing these days.

Re:A standard tab length would be easier

[brianmf]

Using spaces and avoiding tabs is the only way to ensure that a piece of code is rendered consistently in all editors and viewers. Many editors render tabs as 4 spaces, and a lot of editors, terminal programs and utilities render tabs as 8 spaces.

Wait. Doesn't this miss the entire purpose of tabs?

I like to see my code indented by the equivalent of two spaces. The other coders in my team like to see their code indented by the equivalent of four spaces. Do we engage in massive edit wars in cvs? Do we regulate a specific number of spaces so that some portion of the team is unhappy? No. I setup my editor to display tabs as the equivalent of two spaces, and the others setup theirs to look like 4 spaces. Everybody is happy.

Regulating a specific number of spaces is sub-optimal. It totally removes a coders flexibility to see the code how they prefer.

Re:A standard tab length would be easier

[Dun Malg]

I want to be able to indent or unindent the opening statement for a given loop, be it int, sub, function, if, for or else, and have the entire section that it describes, including the braces, indent accordingly. Anyone know of an editor that has this? both vim and emacs will do this. unless i misread the question... I think maybe he's asking for something that moves a whole block of text like (emacs example) Ctrl-Space at beginning, cursor to end, Ctrl-X-Tab... but does so without having to cursor all the way down to the end of the code block, instead just using the indent status of the current line to determine the scope of the requested block indent.

Re:A standard tab length would be easier

[bheer]

I really wonder what code you're writing. In *some* cases, excessive indentation is unavoidable, especially in web environments. But in most cases, excessive indentation is a sign of poor programming, and you should probably recheck your code to see if it can be improved.

Re:A standard tab length would be easier

[Dun Malg]

(formatting fixed. Helpful hints: use preview! copy-pasting misspelled formatting tags replicates the error many times!)

I want to be able to indent or unindent the opening statement for a given loop, be it int, sub, function, if, for or else, and have the entire section that it describes, including the braces, indent accordingly. Anyone know of an editor that has this?

both vim and emacs will do this. unless i misread the question...

I think maybe he's asking for something that moves a whole block of text like (emacs example) Ctrl-Space at beginning, cursor to end, Ctrl-X-Tab... but does so without having to cursor all the way down to the end of the code block, instead just using the indent status of the current

Re:A standard tab length would be easier

[linvir]

There is no bubble to burst. He's just a useful opinionated loudmouth to have on board. I mean, who could be bothered arguing with him?

Re:A standard tab length would be easier

[swansontec]

This is how I code, at least in C-like languages. You can set your tab length to whatever you want, and my sources still look pretty:

int foo ()
{
    //Every line starts with tabs:
    if (
        some_really_long_expression &&
        some_other_really_long_expression
    ) {
        DoSomethingClever(42);
        DoSomethingComplex(
            param1,         //Tabs start the line, spaces between param and comment
            param2,         //Comments line up, thanks to spaces
            param3          //Tab can be any length, whole line moves in or out
        );
        return -1;
    } else {
        return rand();
    }
}

Re:A standard tab length would be easier

[Junior J. Junior III]

How do you say "Fuck you" in Esperanto, anyway? Bablefish doesn't have a translater for that...

Re:A standard tab length would be easier

[Anonymous Coward]

Inform is the *best* example I know of a language that *cannot* be properly indented with only tabs, i.e., spaces are *needed*

Wrong. Your example shows that some code can't be aligned properly with tabs, and that's true. Tabs are for indentation, spaces are for alignment.

Re:A standard tab length would be easier

[peterpi]

And they make the fundamental misunderstanding in the very first sentence! Why is consistency desireable? Why should my text editor render code consistently with yours? We could be using a different font in a differerent point size at a different resolution. Is that important too? I have white text on a black background on one machine, black on white white for the other. If you specifically need some lines of text to be lined up with each other (consistency within the confines of the document), use space. If you just need it to be shunted over to express intent, use tab. That way we can both set tab to look exactly how we want it to.

eg: (---> means 'tab', '.' means 'space')


void foo ()
{
--->if (something)
--->{
--->--->/* I like to format my comments so that
--->--->.* the stars make a vertical line,
--->--->.* but I don't care how much you like to
--->--->.* indent */
--->--->bool something = SomeLongFunction() &&
--->--->.................Another()
--->}
}

This code satisfies everybody with a good text editor. If you like 8 spaces, set your editor so. If I like 2, 7 or 3.14 I can set mine. Pressing space n times annoys everybody who likes 2n, n/2 or any other number of spaces.

That way they can get on with arguing over important issues like the placement of {

;)

Re:A standard tab length would be easier

[peterpi]

Beautiful! :)

Re:A standard tab length would be easier

[What is a number]

I am also of this camp, in that Tabs are only allowed at the beginning of the line. I do get complaints from others about this part:

1.
              param2, // Comments line up, thanks to spaces

if param2 changes (ie, imagine a more complicated line), you waste time re-aligning the comments. Of course, with tabs=3 or 4, you might also need to realign, just not as often.

The other complaint is similar - aligning #defines:

2.

#define Foo 17
#define BARBARBARBAR 18

people don't like aligning these by spaces - it just isn't as quick. Even I don't like using spaces here, but I do it because I believe in tabs-only-for-indenting as the best overall rule.

I'm tempted to either

A. find (or somehow customize) an editor that will change tabs to spaces ONLY in the middle of a line
or
B. make a hot-key that turns tabs=space on/off, so I can turn it on while doing #defines, then shut it off. So my #defines are aligned with spaces, but I used tabs to enter them.

Any other suggestions? 1. and 2. are the only arguments against tabs-only-for-indenting that I think are somewhat valid, and I'd like to get rid of them.

---
I type this every time.

Re:A standard tab length would be easier

[msuarezalvarez]

Yet another application of the old adage saying that the good thing about standards is that there are so many to choose from, I guess...

Re:A standard tab length would be easier

[Anonymous Coward]

Ummmm... no. There's no such thing as sementic info and content info. There is however the concept of semantic information. Tabs do not provide any kind of semantic info. Semantic info is that which provides some kind of meaning to the code (i.e. int a = 0.3 is syntactically correct, but semantically incorrect). Last time I ckecked, whether or not the code has tabs/spaces, the meaning remains the same (to the person and the machine). All tabs and spaces do is make it more pleasant to see the code. Comments provide semantic info (hopefully), but only to humans.

Re:A standard tab length would be easier

[iangoldby]

Unfortunately, as has already been pointed out many times, tabs break alignment when the tab width is changed.

E.g.
^---void myFunction(int a,
^---^---^---^---^---int b);
becomes
^-void myFunction(int a,
^-^-^-^-^-int b);
when the tab width is changed from 4 to 2.

The only way to fix this with ordinary tabs and spaces is to insist that the number of tabs in a particular block is kept constant and spaces are added for alignment, e.g. (with . representing space)

^---void myFunction(int a,
^---................int b);

The trouble is that the difference between tabs and spaces is invisible and it is completely unrealistic to expect a team of programmers to stick to such an error-prone scheme.

My point is that it is no more considerate to insist on tabs than it is to insist on spaces. Both schemes have disadvantages as has already been stated. My personal view is that it is easier to tolerate an indentation width that differs from your preferred, than broken alignment, so I insist on spaces. Of course that is a value judgement, but it is no less valid than yours.

Re:A standard tab length would be easier

[Daniel_Staal]

The point is that usually tabs are used to 'group' lines of code or comments together so they can be understood to be a group. That grouping is semantic, about both the code and the comment. And you are right, at the moment the fact that this done with tabs or spaces or anything else is irrelevant, to both the machine and to the human.

However, it is often done in one specific way, which is easy to use. Hijacking that, and making it both easier to use for the human and more meaningful to the editor would provide an opportunity to solve an argument, and at the same time provide a better coding experience. (Done correctly, of course.) If we can do that, then it might well be worthwhile to do so.

The semantic info is currently in the appearance of the code, when viewed with certain fonts in editors with certain settings. Semi-formalizing the meaning could provide a more robust way to maintain that information, and might have other benefits down the line. (Once it becomes accepted, then editors can use it to do more interesting things with it.)

Re:A standard tab length would be easier

[x2A]

Is to do with a couple of things. Partly, my programming roots (low level assembly etc), I see function calling as a cost, so often inline what other people would ship out to functions. With an optimising, a function can be inlined by the compiler, saving on the call/ret overhead, but there are still sometimes other costs to do with passing values, moving stack frame etc, that can be avoided if you don't program in a way that requires it.

If a chunk of code is to be used in various places, then you have other things to way up when deciding whether you want to inline it or not, such as whether caching benefits of having it as a function outway the overhead of having it as a function.

Everything else comes down to code manageability. Functions having their own context is useful for debugging, but if you're on top of your system (esp if you don't have to worry about recursive/reentrant code), you don't need this layer of abstraction. There's also the layout issues of the source code itself; splitting stuff off into functions can make things neater and easier to follow, which is more important when working in a team.

So yes it can be a bad sign, but it can also just be a sign that the programmer thinks in a different way, structures problems/solutions in their mind in a different way, thus expresses it in a different way. Whether this is good or bad depends (relatively) on the outcome, not what's been taught as "correct".

Re:A standard tab length would be easier

[Tim C]

Which old way would that be? Hard tabs or soft tabs? 2, 4, 8 or X spaces wide. How about a mix of hard tabs and spaces?

Yes, that's the old way.

Re:A standard tab length would be easier

[ESqVIP]

Programmers use tabs (those who do) to convey sementic info.

Would that be some kind of reproduction through whitespace?

Re:A standard tab length would be easier

[Carewolf]

pip??

What does TAB sizes have to do with anything, and especially modern programming?

You might be thinking of indentation, and while there was a time where tabs was used to indent because text-editors couldn't redefine the tab key to indentation width; this time has passed, and there is no reason left to use TABs in programming at all.

Re:A standard tab length would be easier

[Anonymous Coward]

This will always work...

^---void myFunction(
^---^---int a,
^---^---int b);

Re:A standard tab length would be easier

[ceoyoyo]

That's the editor's problem. Well, the editor and the writer.

I use exclusively tabs for indentation. Then, you can choose to view it in your preferred format. Most people seem to like the equivalent of four spaces for indentation. I prefer two. We can both be happy!

If you're using tabs just for indentation to indicate code blocks then it doesn't really matter if the editor changes it, the code is still perfectly readable. Plus, if you're using a decent editor, you can set the space a tab indicates to whatever you prefer.

Re:A standard tab length would be easier

[Breakfast Pants]

Ughhh. If it were so simple everyone could just pipe everything through GNU indent and get everything in the format they want. It isn't so simple.

Re:A standard tab length would be easier

[Breakfast Pants]

That would totally look like barf in my editor where tabs are 0 spaces.

Re:A standard tab length would be easier

[Simon80]

s/shift+i,tab,escape/shift+>/g

Re:A standard tab length would be easier

[turbidostato]

"How can you tell whether nobody will use a new standard if it is significantly better than the old one?"

Because it _cant't_ be significantly better no matter what.

Why do you thing there's still a "tab war" (or a "vim vs. emacs war", for that matter)?

It's because there's no "significantly better" alternative (at least not _within_ then proposed choices).

What (maybe) would be significantly better would be the "standardization by itself". But then, each party will insist on standardize on *his* side, not the other, and this is a sure path for no standardization at all.

Hell, even when there is a really obviously better choice (metric vs. imperial) still there is a terribly strong resistance to standardization against customs.

Re:A standard tab length would be easier

[turbidostato]

"All tabs and spaces do is make it more pleasant to see the code."

Unless you program Python, of course...

Re:A standard tab length would be easier

[CastrTroy]

I just think we should all use whatever we want. Any IDE worth it's salt can reformat the entire file with a single key combo. Just set up the format you're comfortable with, and when you open a file, have it reformat the file to the way you want to view it.

Re:A standard tab length would be easier

[CastrTroy]

Now, just imaging a language without braces, and without requisite tabs.

Re:A standard tab length would be easier

[Ecks]

Emacs does this. C-X R K deletes the rectangle between the point and the mark (outdents) C-X R I Inserts a rectangle.

-- Ecks

Re:A standard tab length would be easier

[Anonymous Coward]

Hi,

> Speaking of tabs, something that I would absolutely love:
> I want to be able to indent or unindent the opening statement for a given loop, be it int, sub, function, if, for or else, and have the entire
> section that it describes, including the braces, indent accordingly.
> Anyone know of an editor that has this?

C-Forge has this feature, I think it's successor, Code Forge IDE, should have it, too:

    http://www.codeforge.com/products/?id=4

Re:A standard tab length would be easier

[Anonymous Coward]

I want to be able to indent or unindent the opening statement for a given loop, be it int, sub, function, if, for or else, and have the entire section that it describes, including the braces, indent accordingly.
Anyone know of an editor that has this?

MATLAB does this.

There was another editor that did this, a long time ago. I think it was Turbo Pascal.

Re:A standard tab length would be easier

[EvilSporkMan]

I hope I never have to maintain your code.

Re:A standard tab length would be easier

[the_womble]

Would that be some kind of reproduction through whitespace?

Well there has to be some way for slashdotters to reproduce - otherwise they would have evolved out.

Re:A standard tab length would be easier

[pppppppman]

On the windows side of things, Visual Studio, by default, has tabs set to a column width of 4 characters. Indent/Unindent multiple lines using standard select+Tab/Shift+Tab. As always, you can go into options and change tabs to whatever you want (8 char column width, 4 spaces, etc.) Quite a non issue. For the record, I use tabs. Column coding is so much easier. Anyone wanna use spaces on my code just do a replace all for to and.. ta da.

Re:A standard tab length would be easier

[Schraegstrichpunkt]

Regulating a specific number of spaces is sub-optimal. It totally removes a coders flexibility to see the code how they prefer.

I don't want to see the code 'how I prefer'; I want to see all the information that the author of the code was trying to communicate to me. This includes the positioning of text.

Re:A standard tab length would be easier

[Schraegstrichpunkt]

Why is consistency desireable?

Source code is a language that allows programmers to communicate both amongst themselves and to the computer. Consistency is desirable for the same reasons that non-lossy communications channels are desirable over lossy ones. If I can see the exact source code that the author of the code saw, then I have a lower probability of making an error in understanding the source code.

Re:A standard tab length would be easier

[iangoldby]

No it won't. The relative horizontal position of 'myFunction' and 'int' changes with the tab width.

Re:A standard tab length would be easier

[smallfries]

Although putting the semantics in the whitespace sounds like a good idea there is a subtle problem - you can see the whitespace. If the tab setting between your editor and the interpreter is different then it can really screw you up. I found this whilst learning Haskell for the first time - made the language a real bitch to learn...

Re:A standard tab length would be easier

[Djofulinn]

I'm totally not seeing the problem that is presented on that PEAR page. Use tabs for identation and spaces for allignment and everyone is happy. The problem is probably editors that automatically change tabs into spaces and vica versa. Which is just as annoying as editors automatically capitalizing words (imagine how annoying that would be in a case sensitive language).

In the examples on the page, everybody can use their own tabsize and everything lines up perfectly.
[tab] is a tab rendered as 5 spaces,
[t] is a tab rendered als 3 spaces,
_ is a space

printf("%s",
_______$arg);

[tab]if ($foo &&
[tab]____$bar) {
[tab]}

[t]if ($foo &&
[t]____$bar) {
[t]}

About consistency: If I set my tabsize to 5, then I want all my identation to be, well guess, 5. If pear fixes theirs to 4 it is inconsistent.

Re:A standard tab length would be easier

[SteveDob]

I don't think the AC was suggesting that the 'myFunction' and 'int's were ever lined up, but that the 'int's would always line up, regardless of the chosen tab length.

Re:A standard tab length would be easier

[Anonymous Coward]

"This code satisfies everybody with a good text editor."

Re:A standard tab length would be easier

[chthon]

Hm, methinks that this was already implemented in typewriters.

Re:A standard tab length would be easier

[smash]

Except it's brain-damaged, and defeats the purpose of tabs.

Just because Jamie is a famous guy who used to work at netscape, it doesn't mean he's right :D

Re:A standard tab length would be easier

[NoMaster]

A standard would be easier. Just have someone say "Tabs are now officially SOME_NUMBER spaces long, so fuck you."

I thought they had...

[History lesson]

Typewriters - very early typewriters - had tab stops equivalent to 8 spaces. That was it; no ifs, no buts, no negotiation. Later models had the first tab stop equivalent to 8 spaces, then 2 or 3 adjustable tab stops inside that. Even later ones had the first stop adjustable was well.

Y'see, the TAB key is short for "table" - it was designed to make it easy to print tabulated data.

Notice I was very careful to say "equivalent" above - a TAB is not equal to 8 spaces! Nor is it equal to 2, or 4, or 6, or anything else you want to dream up. It's a character in its own right; one whose most common representation is as a gap the same size as 8 spaces.

Somewhere along the line, people involved with computers decided that TAB was actually a macro that meant "print 8 spaces". This was a departure from accepted philosophy and, like most such schisms, led to the Holy War that is still going on. And, like most Holy Wars, people come up with brain-dead attempts at reconciliation that ignore the cause of the problem.

Ever wonder why a config file like /etc/sudoers warns you "This file MUST be edited with the 'visudo' command"? No, it's not to prove you're 'leet enough to be editing it by forcing you memorize vi commands; the biggest reason is that the fields are delimited by actual TAB characters. Not spaces, but TABs. Look at it in a hex editor sometime...

In short: there are 2 whitespace characters in ASCII - the space, being the equivalent of 1 (average) character wide; and the TAB, being nominally 8 characters, but able to be represented (not replaced!) by whatever you want. Don't confuse them.

Re:A standard tab length would be easier

[Yer Mom]

I vote for this to be the next Slashdot poll.

How many characters wide is CowboyNeal, anyway?

Re:A standard tab length would be easier

[TeknoHog]

If the tab setting between your editor and the interpreter is different then it can really screw you up.

This isn't a problem with Python, where any consistent indentation works as a block delimiter. You only need the same tab setting (real tab or some number of spaces) within a single block. The only problem comes about if you mix tabs and spaces in the same block so that they look the same; it looks consistent but it isn't to the interpreter.

Re:A standard tab length would be easier

[ynohoo]

Maybe your fear of function calling is related to the fear of global variables prevelent in many languages. Usually because some self-appointed authority said they were "bad".

Like that "Go To Statement Considered Harmful" by Dijkstra, what a prat, what damaged programming he caused.

Re:A standard tab length would be easier

[x2A]

Me too

Re:A standard tab length would be easier

[x2A]

It's not a fear, but a cost I avoid unless there are savings that outway that cost. I don't understand this "functions are always the right thing to do, just to save some tab spaces" mentality that goes on here.

As for globals, no I use them a lot... I'm used to the flat, unprotected model, where you make code that doesn't need to be kept in seperate contexts to stop it overwriting what it's not meant to. You make up for it by writing code in a way that it doesn't need that.

In fact, if you look at early intel papers describing protected mode, it's actually described as a debugging tool, as a system without bugs doesn't need hardware protection, and not using the protection mechanisms results in faster code. This is true of many constructs used in code, such as stack frames. If you can write good enough code, you simply don't need them.

Re:A standard tab length would be easier

[Nurgled]

My rule of thumb is to try always to break on bracketing delimiters like braces and parens. This means that almost all start-of-line whitespace boils down to indenting:

void myFunction(
^---int a,
^---int b,
);

This generally works best if you're writing in a language that doesn't mind spurious separators on the last element, like the comma on the last parameter in my example. If your language doesn't allow this, you need to make sure to keep the commas/semicolons/whatever right when you add/remove items in the list.

Of course, I don't normally do this for parameter declarations, since unless you've got some really crazy functions they are generally quite short, and it doesn't look so hot when two brackety things end up together:

void myFunction(
^---int a,
^---int b,
) {
^---whatever();
}

Re:A standard tab length would be easier

[coats]

Yeah, imagine a language that doesn't need braces because tabs already contain the same semantic (sic) information.

And another: make

Whether a makefile is correct depends upon hidden state: whether the rule-indentation is a tab or a sequence of spaces. It took Stu Feldman (the inventor of make) about three months to realize that this was a bad mistake, but at that point he had an active community of eight users, and didn't want to break backwards compatibility.

;-(

Re:A standard tab length would be easier

[Chapter80]

I disagree with your equivalence statement. I mean, you are correct when the line STARTS with tabs. But when tabs are used after non-tab characters, you are incorrect. Tabs are not equivalent to a PARTICULAR number of spaces - it varies.

Your history lesson is correct - that tab meant to skip to a tab stop. So if you type XYZ{tab}, the tab is equivalent to 5 spaces, where as XY{tab}, it's equivalent to six (assuming a tabstop setting of 8).

My point is that there are two issues: 1. tab stops vs. fixed space insertion are two DIFFERENT approaches (of which various people and editors have certain preferences and implementations), and 2. the length of the space insertion or distance between tab stops varies as well.

You are correct, in my opinion, in saying that tabs are their own character, and it may make sense to preserve that character in the code. Some people use the tab as a shortcut in typing (a navigation shortcut, similar to navigating with the mouse), which is fine, but if they mean spaces, they should either type spaces, or set their editor to convert automatically to spaces (once the line can be decyphered and determined how many spaces the tab is equivalent to, in THIS case.

Re:A standard tab length would be easier

[koogydelbbog]

> In Vim: Press shift+v to highlight the current line, go to the opening brace, press % to go to the closing brace (highlighting the whole block in turn), then press = to auto-indent.

alternatively: go to opening brace (f{ or $) then =% will indent all lines up to matching brace.

Re:A standard tab length would be easier

[k8to]

As usual, tabbers emptily claim their behavior is considerate, when it is not.

I can definitely reindent (spaces or tabs), your entire document if I wish to review it differently, but alignment and subtleties will be broken. However, if I receive a tab-indented document I will have no idea how to displaying to view the intended alignment.

Hard tabs in source are wrong.

Re:A standard tab length would be easier

[Anonymous Coward]

and that's why vi kicks ass. eventually, after you memorize tomes of these shortcuts, it actually becomes somewhat useful. somewhat.
i don't see how >% or % is any more convenient than consistent usage of either [space] or [tab]. i'll just stick with those instead.

Re:A standard tab length would be easier

[Fulcrum of Evil]

Usually because some self-appointed authority said they were "bad".

Globals are bad, says me. When you have to debug some 10,000 line piece of garbage where all variables are global (and that generally means 6 letters or less), you'll say so too.

Re:A standard tab length would be easier

[Anonymous Coward]

I think this is the wrong kind of solution to the problem. A standard would be easier. Just have someone say "Tabs are now officially SOME_NUMBER spaces long, so fuck you." Get Linus to approve of it or something for good measure.

u r rite. I was sick of editors replacing tabs with 3 or 4 spaces. The file looks okay as long as don't switch editors. But if you do, it looks ugly and misaligned. When I press TAB, I want the editor to insert a TAB letter into the file, not 4 spaces.

I have set up my frequently used editors (notepad, visual slickedit, gvim) so that files look the same in all of them.

* An actual TAB character is inserted into the file when tab key is pressed
* The editor is configured to display a TAB character as 4 spaces visually.

To do this in gVim:
:set tabstop=4
:set shiftwidth=4
:set noexpandtab

Re:A standard tab length would be easier

[Fulcrum of Evil]

Except it's brain-damaged, and defeats the purpose of tabs.

No, it sidesteps the issue - code will always have the same indenting, no matter what your editor, and you can enforce consistent indenting with the source control.

Re:A standard tab length would be easier

[Anonymous Coward]

If I can see the exact source code that the author of the code saw, then I have a lower probability of making an error in understanding the source code.

This principle isn't universally true. Suppose the original author wrote the code in a tiny font, because he's an ex-fighter pilot with better than 20/20 vision, and I'm an old man who's about to retire. "Consistency" says I must read the code in the same tiny font that he wrote it in. But this will raise, not lower, the probability of making an error in understanding the source code compared to just using a bigger font.

Programmers should be able to change things that don't matter. The one thing that matters is the meaning of the code: and multiple ways to highlight various elements of that meaning are a good thing.

For example, I have a hard time reading a two-column indent: it's just not enough space for me to read the code without squinting at the screen. It's easier on my eyes if I can make each block indent by four or eight spaces instead. I make more mistakes when I have a headache brought on by eyestrain. Some people prefer to write code in a 2 column indent: obviously, it doesn't bother their eyes much.

If we are to accomodate both types of programmers, we must separate the presentation of the content from the *meaning* of the content. The real issue is how to indicate an indented block, and the answer is to define the tab symbol as meaning a block indent; and let each programmer decide how many tabs it should expand to.

By using tabs as indentation markers (their original purpose on a typewriter, after all!), and by choosing a font that can display tabs as a different symbol from a space, the problem is solved. You can't confuse a space with a tab, since the font tells you the difference. (The jbo of a font is to indicate different symbols differently). You don't need to fight over how a block should *look* to know that a block has been created: the tab symbol indicates that a block has been created. No one has to be unhappy, and the *meaning* of the code remains consistent.

It really is that simple.

Re:A standard tab length would be easier

[Schraegstrichpunkt]

It really is that simple.

Declaring something to be simple doesn't make it so. The reality is that tabs/spaces end up being used for horizontal alignment, as well as block indentation. You haven't addressed that at all.

Also, your example of font size is irrelevant, since changing the size of a monospaced font is not a lossy operation.

Re:A standard tab length would be easier

[CableModemSniper]

I think you meant one of these languages: http://en.wikipedia.org/wiki/Haskell_programming_l anguage, http://en.wikipedia.org/wiki/Forth, http://en.wikipedia.org/wiki/HQ9%2B

Re:A standard tab length would be easier

[corvair2k1]

I'm also of the opinion that gotos are mostly bad. Most of the time, there is a better way to rephrase what you would like to say using a conditional or looping construct. Furthermore, proving program correctness (which is done sometimes) is next to impossible using gotos.

I think over the last five years of coding or so, I have used gotos twice in committed code.

Re:A standard tab length would be easier

[smash]

Why should I have to hit space 4 or 8 times instead of hitting tab once (presuming tab isn't redefined to x spaces, which is a broken idea. TAB key = TAB character)?

What if I don't *WANT* the same level of code indenting? Personal preference is 4 space tabs, linus for example likes 8 spaces. I know some who like only 2 spaces.

Either I

• go through the file and delete all the spaces and replace them with the "Correct" number of spaces (brain damaged) OR
• I set the "tab spacing" in my editor to a sane value and bingo, it's done

It's not a religous issue, it's a fucking "non-issue"....

If your code is that fucked that it's not readable/understandable when you change the tab spacing, you've got more serious problems to worry about.

As far as source control goes - all CVS/whatever sees is a tab character. It's expanded when viewed. Non-issue.

Unless you've got a broken text editor that replaces the TAB character with X spaces...

my 2c... (curse words not intended to cause offense, it's simply to illustrate the strength of my feelings on the matter :D)

Re:A standard tab length would be easier

[RDFozz]

Ten. Duh.

Re:A standard tab length would be easier

[Fulcrum of Evil]

Why should I have to hit space 4 or 8 times instead of hitting tab once

Because you're not using Emacs.

What if I don't *WANT* the same level of code indenting?

You either change the tag at the top of the file that says what sort of indents you have or leave them alone. Anything else leaves you open to the BPFH and his many sharp toys.

go through the file and delete all the spaces and replace them with the "Correct" number of spaces (brain damaged) OR

Tell emacs to auto indent with the new settings, duh.

If your code is that fucked that it's not readable/understandable when you change the tab spacing, you've got more serious problems to worry about.

If it varies from fil to file, it's a pain in the ass. This is called living with coworkers.

Unless you've got a broken text editor that replaces the TAB character with X spaces...

With EMACS, all things are possible.

Re:A standard tab length would be easier

[Mr. Jax]

The problem with this coding style is:

1. In your really_long_exp you wrap and continue at the beginning. When reading your code it look like the second line is a statement on it's own.
2. In DoSomethingComlex you continue with 1 extra tab for wrapping. This is inconsistent with 1. Also a tab is used to indicate a new 'block' of code.

For 1 & 2 some people prefer to use 2 tabs or some other rules. It is in these cases that using different definitions of TAB can render the code not so readable.

Re:A standard tab length would be easier

[Anonymous Coward]

This code satisfies everybody with a good text editor. If you like 8 spaces, set your editor so. If I like 2, 7 or 3.14 I can set mine. Pressing space n times annoys everybody who likes 2n, n/2 or any other number of spaces.

Exactly.

I think that people are split in two groups: The "content"-group and the "layout"-group. I call them so, because I see the same thing with web-pages.

The content group prefer tabs, one tab indicates another level of indentation, which can be 3,4,8 or 10 spaces depending on who is looking at the code. Everyone gets to see the code in the way most readable for him. These are the same people who when writing a web page will specify "h2: font-size: large", and lets the user decide what size is the most readable.

The layout group are the people who want "my way, not your way". The code has to look the same as on their own screen, no matter how unreadable everyone else thinks it is. They use space for everything, and then argue among eachother about 3,4, 8 or 10 spaces. When writing a web page, they will set the font size to 8 pixels, without caring that the viewers screen is 250 DPI, make the webpage into columns that overlap or goes outside the window (with no way to scroll) if you aren't running your browser maximized in exactly 1280x960, and use GIFs for the headlines. That is, if they don't make everything a f**king PDF file.

Re:A standard tab length would be easier

[Oliver_Etchebarne]

I am in no way affiliated with Editplus or the company behind it, just a happy user.

I was a editplus happy user, until I found SciTE :)

Works very similar to Editplus, it has per-language configuration, sintax coloring, auto-ident, and a lot more. And the best of all, it's open source.

Word?

[MindStalker]

Umm Word has been doing this for year.

**Runs**

From Wiki

[neonprimetime]

Use of the term "Holy War" implies that the root of the disagreement is a clash of values, and intractible of resolution except by agreeing to disagree.

My bible says it is morally wrong to use Vi.

Re:From Wiki

[ClayDowling]

Hmm, that definition pretty much described the whole vi/emacs thing pretty well. All those backward vi-using heretics out there just don't get it.

Re:From Wiki

[Kesch]

:s/Vi/Emacs/g

Re:From Wiki

[jc42]

My bible says it is morally wrong to use Vi.

Well, of course it is. VI is Latin for 6, which is 1/3 of 666, and we know what that stands for.

As further proof, check vi's origins. It came from Berkeley, and their BSD system has a little d[a]emon as a symbol. Spawn of Satan, QED.

Re:From Wiki

[DesertWolf0132]

Mine says,

"And behold sayeth the Lord, thou shalt edit thine text in Vi and Vi alone, even when thou art forced by the unclean luser to useth the operating system of unholiness. Thou shalt always keep a copy of the Holy editor on thine key of the USB lest thou shalt fall into temptation and edit thine text in the way of the unclean. Any who useth Emacs or the accursed notepad shalt be stricken from the Book of the Holy Sysadmin for all eternity. So sayeth the Lord." -1st Epistle to the Admins of Systems 1:15-16

There it is in black and white. Vi is the way of truth and light. All others are unclean.

Re:From Wiki

[foniksonik]

Hmmmm I went searching for "The EMACS Bible" book... figuring that it was the bible you had to be referring to but was confounded by the fact that one apparently doesn't exist... so maybe you've got a copy of a Lost Translation or something...

...closest i could find was the The Linux Bible: The Gnu Testament - so maybe this is what you were referring to ;-p

Re:From Wiki

[base3]

Well, of course it is. VI is Latin for 6, which is 1/3 of 666, . . .

Actually, it's 1/3 of 18 :). And I use VIM, which could be 1,006 if you abused the rules enough.

Re:From Wiki

[neonprimetime]

No silly, I wrote my own bible. And I read from it every day.

Re:From Wiki

[Ed Avis]

Nope, afraid not. vi is a modern-day abomination. Ed is the standard text editor.

Re:From Wiki

[kimvette]

However, in the second book of Coders, 1:2-5, we find the following:

2 And BOFH called a little coder unto him, and set him in the midst of them, 3 And said, Verily I say unto you, Except ye be converted, and become as this emacs user, ye shall not enter into the kingdom of unix. 4 Whosoever therefore shall humble himself as this little coder, the same is greatest in the kingdom of unix. Then were there brought unto him other little coders, that he should put his hands on them, and give them emacs: and the admins rebuked them. 4 But BOFH said, Suffer little coders, and forbid them not, to come run emacs: for of such is the kingdom of unix. 5 And he compiled their emacs, and departed thence.

I call contradiction!

Re:From Wiki

[techno-vampire]

There it is in black and white. Vi is the way of truth and light. All others are unclean.

Fi on vi! Emacs forever!

Re:From Wiki

[DesertWolf0132]

Vi came to fulfil the law of Ed as Christ came to fulfil the law of Moses. Come forth into the baptism of the Holy Vi and be saved!

Re:From Wiki

[DesertWolf0132]

You left out verse six:

6. And behold the emacs did vex their souls for the BOFH hateth the coder who is loathe to select and compile an editor unto himself and loveth those who shalt compile for themselves the holy Vi. Yea verily I say unto thee that from that day those coders fell into error such that the BOFH sayeth, "This bringeth joy to my soul as great as the Holy Lager, that these coders might vex themselves with that which is unclean." 7. And the BOFH did laugh much at the pain he hath sent out upon the coders.

Re:From Wiki

[DesertWolf0132]

Get thee hence oh user of the unclean editor! Depart from me oh worker of bloated ascii manipulation! In the name of the Holy :q! I command the, depart!

Re:From Wiki

[kimvette]

Ah but does it not also say "edit others' files as you would have them edit yours?"

Re:From Wiki

[Samurai]

And I use VIM, which could be 1,006 if you abused the rules enough.

Allowing for that sort of "abuse", VIM should be 994 (1000 - 6), not 1006. Or are you really using MVI? :)

Re:From Wiki

[ryu1232]

Thou shalt not Commit ed-dultery

Re:From Wiki

[Schraegstrichpunkt]

What if someone ports Vi to Emacs?

Re:From Wiki

[Anonymous Coward]

:s/Vi/Emacs/g

Shouldn't that be META-F, META-Q, CTRL-K, F3, Q, S, META-F17?

Re:From Wiki

[Mr. Slippery]

What if someone ports Vi to Emacs?

It's called VIP.

Re:From Wiki

[StikyPad]

Pico > All

Re:From Wiki

[base3]

True. I don't know if VIM is even valid--unless the subtraction rule works for > 1 character to the left. Not using MVI :).

Re:From Wiki

[Anonymous Coward]

By now, Emacs should be capable of writing its own bible.

Word is a shitty text editor.

[Ayanami Rei]

I mean, the same could be said for, let's say, PageMaker. Or OpenOffice. Or a lot of text layout tools.

But code editors they are not.

We brough content folding and syntax highlighting to text editors. Now it's an appropriate time to bring them layout magic, I suppose.

Re:Word is a shitty text editor.

[KarmaMB84]

Microsoft seems to manage auto-indenting just fine in Visual Studio and VS Express.

What does this solve really?

[Anonymous Coward]

Tabs may be plain fucking wrong but it doesn't matter much with Vim so I'm curious what problem elastic tabstops are meant to solve?

BTW: indents should be 2 spaces and code should be manually wrapped at 76chars, anything else is for failures!

Re:What does this solve really?

[DesertWolf0132]

I too use 2 space indents but find the nice round wrap of 80 works better for me.

Tabs get strange when you edit in Vi and everything is nice because you set the tabs correctly and you send it to a cow-orker who uses, Lord have mercy on me for the unholiness I am about to utter, Dreamweaver, and decides to tab everything and then send it back after it has been "cleaned up" by Dreamweaver and it looks like a rat's nest. Then you are forced to LART them into next month for both using such an inane program and "cleaning up" your code with it.

Re:What does this solve really?

[techno-vampire]

Lord have mercy on me for the unholiness I am about to utter, Dreamweaver...

Y'know, there really ought to be a way to use rot13 on Slashdot so that innocent eyes wouldn't have to see things like that. Think of the chillllllllllldren!

Re:What does this solve really?

[trashbat]

The following Normal mode command in Vim will reindent your whole file for you according to the indenting rules for that language (user-defined, or the Vim defaults): gg=G Want to get rid of that annoying, end-of-line whitespace that's been inserted all over the place? :%s/\s\+$//

Re:What does this solve really?

[trashbat]

Something tells me I should've hit 'Preview'...

The following Normal mode command in Vim will reindent your whole file for you according to the indenting rules for that language (user-defined, or the Vim defaults):

gg=G

Want to get rid of that annoying, end-of-line whitespace that's been inserted all over the place?

:%s/\s\+$//

How we got here

[Animats]

The way we got into this mess is that in early versions of UNIX, tab stops were set to 8 spaces in the TTY handler. This was not because tab stops were intended as indentation. It was because an ASR-33 teletype could tab that far in one character time. It was for optimizing output time. (Back in those days, TTY output processing had to have time delays to handle the mechanical lag in printers. "How many nulls were required after each carriage return" was an issue, and better systems kept track of the printing column position and adjusted the delay accordingly. Peripherals used to be really dumb.)

If some reasonable indentation value like 4 or 5 had been chosen, everything would have been fine.

Re:How we got here

[Mr Z]

Not just mechanical output devices. I wrote a TTY driver for a Viewpoint terminal that I was driving from an 8052. That thing needed delays all over the place. (Imagine my surprise, years later, to open one up and find an 8051 sitting in there.) I actually discovered it needed delays from the UNIX side of things, because the first thing I implemented was a serial-to-serial pass through, and I had to mess w/ the various stty delay settings before I stopped losing text.

But, yes... 80 columns goes back to Hollerith, and 8-column tabs goes back to an old teletype.... and yet these standards persist. :-) I personally expand all tabs to spaces just to avoid tab damage. I've gotten some horribly dainbramaged files over the years and never like being on the receiving end of that.

--Joe

Re:How we got here

[Haeleth]

If some reasonable indentation value like 4 or 5 had been chosen, everything would have been fine.

No: if some reasonable indentation value had been chosen, tabs would have been less useful for their intended purpose, namely tabulation.

The idea was to let you make a table (of numbers, for example) easily by entering

1[tab]32[tab]1.268[cr][lf]
992[tab]5[tab]whatever[cr][lf] ...and it would all line up nicely without you having to work out how many spaces to insert. 8 was a suitable value for most purposes.

It only became a problem when people started misusing tabs for other purposes.

whether or not this solves the problem

[yagu]

Whether or not this solves the problem (I don't think it does), I get real nervous when source code starts being perceived as a document that lends itself to proportional fonts. Maybe I haven't been in the latest and greatest IDEs lately and am missing something here, but source code seems to scream for canonical form, and proportional font is not that.

I think vim has a reasonable approach (do the research: shiftwidth, tabstops, softtabstop, etc.), I assume there are other approaches in emacs.

Start talking about proportional font source code documents, and now everyone's going to want to have styles, and all the confusing garbage that is word processing. As difficult as source code and programming is, it doesn't need to be more nuanced in word processing.

Re:whether or not this solves the problem

[Infernal Device]

You do realize that turning off the styling is as simple as selecting all the text, then changing to one standard font at one standard size?

Not that I'm for it ... well, maybe a little. It would be nice to have bold and italic.

Re:whether or not this solves the problem

[Anonymous Coward]

This new system still uses plain old ASCII files!

Re:whether or not this solves the problem

[chthon]

Literate programming

Re:whether or not this solves the problem

[bogado]

I think that this is good, I aways thought that tabs for identation is simply a better idea just because it made simple for people to see the code the way they feel more conforable with. I don't think 'styles' is a problem, it is just the oposite, imagine if we could make a "style sheet" of some sort and apply to the code and sudenly all the code you load into your editor is styled as you liked?

I use the command line program ident to apply my style to other people's code, sure I don't send them this way I read the code and then just 'undo' before altering the file. But all of this would simply be better if we could style the code without touching it.

Re:whether or not this solves the problem

[mdfst13]

"imagine if we could make a "style sheet" of some sort and apply to the code and sudenly all the code you load into your editor is styled as you liked?"

Yeah, but people would still screw it up.  For example:

  // K&R style -- comments on the if/else go before
if () {
  // comments on the if clause go after the first {
} else {
  // comments on the else go after the else {
}

  // BSD style
if ()
{
}
else
{
}

  # Conway style
if () {
}
  # This also is a problem with BSD, but I thought I'd put it here.
  # Comments on the else clause go between the closing } of the if
  # and the else {.  Net result?  Hanging elses.  I.e. someone removes
  # the if () {} but does not realize that there is an else.  Further,
  # since an if can only be closed by lookahead, this results in real
  # oddities, like the else clause attaching to the previous if.
else {
}

I find the last to be the single ugliest syntax.  The theory behind it is that it is best to put keywords in the left most column.  However, the problem here (IMO) is that an else is irrelevant without the surrounding block structure and the if.  Thus, IMO, it makes sense to write it } else {, as that indicates that the } does not close the if; instead it closes the if true clause before opening the else not true clause.  I actually prefer BSD as being more consistent.

Anyway, the problem that your stylesheet would have is that the syntaxes are fundamentally incompatible.  In BSD and Conway, you can put line comments (//) after the } and before the else.  In K&R, you can't.  Now, you might argue that the stylesheet could move the comment.  However, if you do that, then you lose information.  Why?  Because any other location for the comment in K&R already has an equivalent in BSD/Conway.

What's really needed is a single, canonical way of formatting saved code.  Then developers can apply the stylesheet to the canonical form when viewing.  This canonical way would have to prohibit those practices that only work in some of the representations but not others, e.g. comments in between } and else. 

Re:whether or not this solves the problem

[bogado]

I totally agree with you, hanging else's are awful style. I like to use doxygen style of comments, and for comments inside the functions I tend to make them as little as possible. Sometime is more useful to make things clear in the code.

Surely that switching styles is yet a bit harder, it should be possible to do it. But while we don't have this panacea, why not using tabs for identation? I certainly don't know why this pratice is so much hated, for me is the only pratice that makes sence. It makes easy for computers to parse it, so they know the intention of the author and can then format the best way.

Re:whether or not this solves the problem

[5937]

Whether or not this solves the problem (I don't think it does), I get real nervous when source code starts being perceived as a document that lends itself to proportional fonts. Maybe I haven't been in the latest and greatest IDEs lately and am missing something here, but source code seems to scream for canonical form, and proportional font is not that.

Oberon, (not the latest IDE albeith the greatest;) uses a full word-processor. Some forthes allow embedded html, so source can be formatted. And where such things are lacking, people want at least syntax-highlighting. So, why not?

A Tab is one character that represents 8 spaces.

[caseih]

Tabs have been and should continue to be what they are. If you need to format code within the 8 spaces, then use a tab. Otherwise use a space. In no other way can we get source code that looks consistant across editors and platforms. Especially in neat languages like python. Attempts to redefine tab stops are misguided. And don't even get me started on the use of proportional fonts in programming editors. Heresy.

Well, that's a broken idea

[roystgnr]

Start up his Java editor, and replace the line:

[TAB]if (1)

With the line:

[TAB]if (this_sucks())[TAB]/* Always returns true */

And watch as the tab spacing of "lalala();" two lines down gets ruined.

He's right that mandating "tabs must be N spaces" is stupid, though. Use tabs to indent blocks of code, use spaces for aligning code that isn't in blocks, and people should be able to set whatever tab size they want without ruining anything.

int myfunc(int arg1,
          Class arg2) /* use spaces here*/
{
[TAB]assert (arg1 != arg2.size() && /* and tabs here */
[TAB] arg2.is_valid()) /* and a mix here */
}

Now, let's see if I can keep this from being mangled by Slashcode...

On preview: no, I can't. Well, imagine that the C in Class is directly under the i in int, and imagine that the a in arg2.is_valid() is directly under the a in arg1.

Of course, getting this right every time isn't easy when you're trying to think about your code and your editor has it's own ideas about indentation. I'd be very happy if anyone could tell me how to get Vim's autoindent to behave this way.

Re:Well, that's a broken idea

[Nerdfest]

I completely agree with you ... but that's not going to help, even if I'm Linus (which I'm not). This is a _religious_ war, and using common sense and reasonable arguments is the last thing you want to do.

Re:Well, that's a broken idea

[Albert Sandberg]

You just *had* to break it didn't you? ;-)

Re:Well, that's a broken idea

[Anonymous Coward]

"And watch as the tab spacing of "lalala();" two lines down gets ruined."

Then either don't put the comment there or insert a new line. Personally I like the way the comment blocks slide across when editing the text...

Re:Well, that's a broken idea

[Anonymous Coward]

Ahh, but in your 2nd example you're using spaces for indenting. I suppose a semantic way I would do it would be:

int myfunc(
[TAB]int arg1,
[TAB]Class arg2)[TAB]/* use spaces here*/
{
[TAB]assert(
[TAB][TAB]arg1 != arg2.size()[TAB]/* and tabs here */
[TAB][TAB]&& arg2.is_valid())[TAB]/* and a mix here */
}

or something like that.

Re:Well, that's a broken idea

[kent.dickey]

I played with his editor for a little while, and found the same kinds of problems the parent author found. It's especially bad if you try to cut&paste code from another area in place--the formatting goes crazy. I thought it was neat how the comments at the end of the lines would move around automatically, but it's easy to get it to do odd things and to not format code well at all. The whole things feels like the computer is about to do something unexpected all the time.

I think the author is solving the problem the wrong way. His solution has the undesirable property that a relatively small change can change the formatting for a large block--and then the user must go fix things.

I know it's a hotly-debated topic about formatting code, but the #1 rule for formatting code is: You must have a rule for formatting your code. If you don't then your code is a lot less readable. Pick a style and stick to it.

My style: I find the constraints of using tabs to indent to 8-character tabstops and having a hard 80-column line limit helps enforce good readability, for C/C++ and Verilog code. If your code starts crowding the right hand-margin, you have to move code into a function which you then call, so you can start over against the left margin in that function. These simple rules eliminate a lot of difficult-to-read code by simply not allowing you to get 6 levels deep with logic which should be refactored for readability. Sometimes working with and embracing some limits forces the coder to have better discipline. I don't like 2-space indents since it's just not enough to make it easy to scan through code, and it encourages a complex coding style (you only need 2-space indents if you're nesting many levels deep). And I think all code should have a line limit, and 80 is a natural choice. Sure, you could pick 145 or whatever, but I've found code using much longer lines to almost always be harder to read. And 80 colums prints 2-up at a still readable size on a printer, so I can view more lines at a time when scanning through printouts.

Re:Well, that's a broken idea

[Anonymous Coward]

You shouldn't be imposing your wrapping of arguments on others in the project any more than you should be imposing your indentation preferences - use tabs, let the editor visually wrap without putting it in the file. Not that I would ever waste a whole screen line for a single parameter, but I think you could do what you're asking with a VIM syntax file.

Oh... Honestly!

[Greyfox]

(setq-default indent-tabs-mode nil)

Then emacs will replace tabs with spaces. In the various programming language modes, tab indents to the right location (Which you can customize somewhere else.)

vim has a similar setting but I rather despise vim (I prefer nvi or old school vi when doing vi things.)

Re:Oh... Honestly!

[Anonymous Coward]

In other words,

"Vim tastes so bad I would rather eat dirt instead"

Vim would have to be doing something pretty fucking bad for you to actually have a reason to prefer a vi with a 1-level undo not even to mention no unicode, no macros, no language-based highlighting or indent, visual bell, no completion, ... etc

Look I don't like emacs. I don't often need to program my text editor or read email from it. I find "set expandtab" much easier than "(setq-default indent-tabs-mode nil)". But I'm not going to troll and say I like "gosling emacs circa 1978" better than xemacs. I mean really wtf?

Re:A Tab is one character that represents 8 spaces

[jc42]

Wrong. A TAB represents 1-N spaces, depending on the current column, where N is the tab setting. I've never seen a TAB interpreted as a fixed number of spaces, and I've seen a lot of output devices in the 40 or so years I've been playing with computers. TABs move the output position to the next tab stop, not some fixed number of spaces.

Brilliant!

[DoofusOfDeath]

What a great social engineering trick - get 30% of Slashdot readers to locally execute untrusted code with local thought. Cracker, my hat is off to you!

Re:Brilliant!

[Anonymous Coward]

MOD PARENT UP!

Re:Brilliant!

[Anonymous Coward]

Don't worry - it's Java!

YESSSsssss

[Anonymous Coward]

Innovation at last!

- Bill

It's not a comment about Microsoft.

[Ayanami Rei]

So, uh. What the fuck does VS have to do with anything?
I've never used it so I can't comment. So it has variable-width fonts and logical indenting and spacing? Good for them.
If it appears in anything _besides_ Visual Studio I'll be a happy camper.

Re:It's not a comment about Microsoft.

[Schraegstrichpunkt]

I don't think Visual Studio uses variable-width fonts. At least, not by default. Even Microsoft isn't that insane.

Re:It's not a comment about Microsoft.

[Anonymous Coward]

I don't think Visual Studio uses variable-width fonts. At least, not by default. Even Microsoft isn't that insane.

A colleague of mine uses a source code editor where part of the syntax highlighting scheme is to change the size of the fonts. For example, regular code might appear in normal 12-point type, whereas function names might appear in a huge 16-point type. (Just to make up some numbers.)

Of course the indentation looks completely haphazard to anyone else working on the code, but "luckily" he doesn't care about things like that.

Re:It's not a comment about Microsoft.

[Schraegstrichpunkt]

Hmm... Coding in FrontPage...

/me shivers

Re:A Tab is one character that represents 8 spaces

[caseih]

I can grudgingly accept the arguments of the web site mentioned in the summary, but I am not convinced their solution is the answer. Certainly it will only work if *all* text editors work that way. And that is not likely to ever happen.

Re:A Tab is one character that represents 8 spaces

[Anonymous Coward]

Using 8 is idiotic. 2-4 spaces should be enough for anyone. This is why I always convert tabs to space anyways.

Yeah, but...

[cerberusss]

... will it run make?

This could be a boon in IDEs, but...

[Borealid]

If you play with the demonstration editor a bit, you can see that this has potential.

BUT, I think it would only be useful in editors with some syntactical idea of the code they're editing, like Netbeans/Eclipse/vim and so on. In the demo editor, for example, tabbing will properly indent code only if you put a brace on its own line. If you don't, you get this:

if (blah) {
                                                      foowayoverhere();
}

Because it indents the next code too far, treating it as a comment. This idea could be very useful to coders, but it's really not for normal documents and it should not be implemented in editors where the format of the file is not known or completely understood.

But for XML editing...

Re:This could be a boon in IDEs, but...

[Anonymous Coward]

That only happens if you put a tab at the end of the line with "if (blah) {" on it.

Remove the tab and it works fine. I think some people may have to change their coding style a little, but if they can get over that hurdle I think the benefits could be huge!

Re:This could be a boon in IDEs, but...

[Borealid]

That only happens if you put a tab at the end of the line with "if (blah) {" on it. Remove the tab and it works fine. I think some people may have to change their coding style a little, but if they can get over that hurdle I think the benefits could be huge!

Or, you know, have another level of indenting anywhere within the block between the two closest empty lines. The tables are separated by empty lines. This means that if you have something at a third-level indent in one block, and only go to the second level in another block, adding a "//" to the front of the empty line between the two can cause stuff in the second block to "jump" over to the side.

Re:This could be a boon in IDEs, but...

[Anonymous Coward]

"This means that if you have something at a third-level indent in one block, and only go to the second level in another block, adding a "//" to the front of the empty line between the two can cause stuff in the second block to "jump" over to the side."

Ah, so you have a blank line separating 2 blocks which you unblank by typing "//" into it. This joins the 2 blocks together into 1 block. The solution is obviously to create another blank line and thus seperate the 2 blocks again.

The REAL problem with tabs vs spaces

[Anonymous Coward]

The "tabs vs spaces" debate is an all-or-nothing religious war/social problem disguised as a technical problem. There are merits to both sides, but the debate will never end because there is no satisfactory compromise between the two opposing factions. The "elastic tabs" method presented in TFA is a misguided attempt because it proposes a technical solution that does not appease either sect, and it may even generate a third "religion" in this holy war.

For those new to programming, I'll let you in on a dirty little secret: for any given language it is always possible to parse and reformat the code to ones liking (e.g. indent, astyle, etc); therefore, the tabs vs spaces debate is completely moot. If Sam likes spaces and Tom likes tabs, they can both have it their way when they're editing code. Manny (their boss) can even insert a check-in filter that indents the code to his preference, a random mixture of tabs and spaces, just to remind them that he's the one in charge. Experienced programmers realize this, so we don't take part in such debates.

In conclusion, if tabs vs spaces really matters to your project, just install a check-in filter and shut up already. Some of us have work to do.

Re:The REAL problem with tabs vs spaces

[LordByronStyrofoam]

Wrong on three counts: make(1), source code management systems and tools like diff and patch, and python source. Make requires a tab to begin a command line. diff will show you and your coworkers all the silly changes you just committed to the repository because you set your editor to convert tabs to spaces. And Python is easily confused when tabs and spaces are mixed.

Source code is not a table

[Anonymous Coward]

Tab is short for Tabulate - make into a table. Source code is not a table.

If you want to represent data in a tabular form then use tab stops and the tab character to separate the data items such that when it is displayed the data items form columns.

Source code for most languages is not like that. It happens to be convenient to use the 'tab' key as if it were an 'indent' key and space can be saved on disk by representing a number of spaces by a single character, but the 'tabbies' are confused.

It happens that _some_ languages are 'tabular'. Assemblers, for the most part, are best represented in columnar form. Perhaps the tabbies are locked into the 1960s when programs were written on 'card punch forms' and a format card was used to set the tabstops for the punch girls, but the cards had _spaces_ on them as Hollerith intended, the tab key did _NOT_ punch a tab character into the card.

I do use the tab key as a means of stepping along a number of spaces but the resulting files has exactly the number of space characters that are necessary and no tab characters at all.

Re:Source code is not a table

[DrMorris]

I do use the tab key as a means of stepping along a number of spaces but the resulting files has exactly the number of space characters that are necessary and no tab characters at all.

Yeah. And this is exactly the way it should be today. In mature Emacs modes for example, pressing the TAB key doesn't necessarily mean that you insert an ASCII TAB character, instead it indents to the right place. Modern editors should take the burden of 'manual' indenting from the coder and instead let him focus on the semantics (without introducing a new 'standard').

Re:Source code is not a table

[Anonymous Coward]

asdf

Re:Source code is not a table

[grmoc]

A tab == X spaces (at the beginning of a line, at least).
This may seem obvious, but it is also powerful-- it means that I may indicate, symbolically (i.e. by usng tabs) the indentation level of a piece of code, etc.

Thus, I mix tabs and spaces according to the following:
The number of tabs at the beginning of a line is equal to the number of open scopes. Everything from then onward is spaces.
This means that whatever someone uses as their tabsize, the code will display correctly, regardless of whether that someone likes two-spaces per indent, 4, or 8, and it is trivial for them to change the format to display it at their preferred indentation level.

When one uses spaces, this is often not possible. You can assume that N spaces means one indent level, but often people will get it wrong, and in order to change how you view the indentation, you actually have to change the file.
If you're using some kind of versioning system, this may not be good-- If you forget to change it back, then you have modified the fie without adding any new content (i.e. created a spurious change).
I'd hope that people would agree that being able to at least -view- a file with one's preferred indentation level will lead to a quicker understanding of the code.

Re:Source code is not a table

[Nurgled]

This scheme seems fine until you encounter a stubborn developer that uses proportional fonts. There's one such developer at my company, and he doesn't even just use one proportional font: I think his editor uses regular Tahoma for most text, but renders strings in something else (not sure what) and comments in Comic Sans MS. He's always screwing up my lining-up-with-spaces, but at least my tabs-to-indent stay intact.

Re:Source code is not a table

[bogado]

By the same standard, why should the coder care if there is a "tab" character or a few space character? If the code is layed out in the way he or she want's to visualize. I just think it is better that a single character represent a identation and not a random number of spaces. If a code file is encoded with tabs for identation my editor, be it vi, emacs or every single IDE can figure out where are the identations and apply my preference as how far should those identation should be shown.

No but many people know better then me on how should I look at code, after all they are the holder of the holy truth and so they ident with spaces, or even worst with a mix of spaces and tabs that only work if you set the tabstops to a weird number like 3 or 7 (sure I am exagerating here), that is anoying...

What I believe is that every one has a preference, and computer are smart enougth to layout the code as you prefer. This article is about that, editors choosing the best way to display a program.

Bad diff

[SuperKendall]

The problem is depending on what source control system you are using you may get screwed over by diffs looking really bad depending on how it thinks of whitespace.

Otherwise I agree with you, and personally I would always opt for a version control system that would let people reformat code whitespace to their liking.

Not really a compromise.

[ishmalius]

He implies that this is a middle-ground solution, however, this "solution" is of the opinion that tabs are what are intended for formatting. So it's really not a compromise at all, but an evil Tabbist plot! (j/k) ^^

but it is hoped that many editors will be updated to support this new way of interpreting tab characters

Hoped by whom?

However, this type of formatting has been around for a while, in better language-sensitive editors, where you can adjust for formatting for the various coding contexts.

A better compromise would be to read any given code file for the given language, sense the coding style of the original document and interpret and display it on the editing widget in the manner you think the author wanted. Preserve the original document internally as a document tree and at save time, either save in exactly the same coding style as the original, or in the style the user wants. This would be similar to XML DOM readers that preserve an exact model of the original document in memory. And it is displayed according to its semantic meaning, not a tab or space count.

This would respect the coding style of the original author, while giving options to the user of the editor. A much better compromise, I think.

Re:Not really a compromise.

[Proteus]

This is why I like PerlTidy. Various coders I work with like different styles, and they simply run PerlTidy with their own settings on any code before they edit it -- that way, it looks the way they want it to.

Our source control repository is set up to run the project-standard PerlTidy against check-ins so that the deltas are minimized and all source files are in the standard format. Problem solved.

If this can be done with Perl (which is annoyingly hard to parse), why not with other languages?

Re:No, No, It's Not the Length of the Tab!

[aslate]

NEVER use tabs in code - or if you do, use an editor like jEdit that can automatically change them to spaces.

Or when you edit code and just have to change someone else's layout, do a find-replace on tabs with however number of spaces you want instead?

Re:No, No, It's Not the Length of the Tab!

[Doctor Crumb]

So, um, *what* better editor? jEdit doesn't seem to have features that vim or emacs lack, which is good, but it doesn't seem to have a console-only version, which makes it entirely useless to me and anyone else who programs on a remote machine over ssh. You're just insulting people without offering any reasonable alternative, and proving that you are nothing but a rabid fanboy. While you froth at the mouth, I'll be over here, doing some programming in an editor that will actually run on the machines I work with.

The subject of tabs vs spaces should be clear

[frn123]

The subject of tabs vs spaces should be clear enough to everyone.

Let me quote the relevant standard:

Linux kernel coding style
[cut]
First off, I'd suggest printing out a copy of the GNU coding standards,
and NOT read it. Burn them, it's a great symbolic gesture.
[cut]
                  Chapter 1: Indentation

Tabs are 8 characters, and thus indentations are also 8 characters.
There are heretic movements that try to make indentations 4 (or even 2!)
characters deep, and that is akin to trying to define the value of PI to
be 3.

Rationale: The whole idea behind indentation is to clearly define where
a block of control starts and ends. Especially when you've been looking
at your screen for 20 straight hours, you'll find it a lot easier to see
how the indentation works if you have large indentations.

Now, some people will claim that having 8-character indentations makes
the code move too far to the right, and makes it hard to read on a
80-character terminal screen. The answer to that is that if you need
more than 3 levels of indentation, you're screwed anyway, and should fix
your program.

In short, 8-char indents make things easier to read, and have the added
benefit of warning you when you're nesting your functions too deep.
Heed that warning.

[cut]
But even if you fail in getting emacs to do sane formatting, not
everything is lost: use "indent".

Now, again, GNU indent has the same brain dead settings that GNU emacs
has, which is why you need to give it a few command line options.
However, that's not too bad, because even the makers of GNU indent
recognize the authority of K&R (the GNU people aren't evil, they are
just severely misguided in this matter), so you just give indent the
options "-kr -i8" (stands for "K&R, 8 character indents").

"indent" has a lot of options, and especially when it comes to comment
re-formatting you may want to take a look at the manual page. But
remember: "indent" is not a fix for bad programming.

Linus Torvalds.

Re:The subject of tabs vs spaces should be clear

[Anonymous Coward]

The "standard" you are quoting is relevant to kernel programming in C only. For example:

The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.

Okay, one level of indentation for a class' members. One level of indentation for a member function. That leaves one level of indentation for loops, conditionals etc. Are you really saying that nested ifs mean your program is screwed? That it's impossible to have a sanely-designed loop that has an if statement in?

Re:The subject of tabs vs spaces should be clear

[EvilSporkMan]

Why are you writing all your (C++, I'm assuming) class members inline?

Re:The subject of tabs vs spaces should be clear

[Anonymous Coward]

Python actually. But why wouldn't you write class members inline in C++? It makes sense to define all the class members within the block that defines the class.

Re:The subject of tabs vs spaces should be clear

[bogado]

It also makes sense to separate the implementation from the interface definition, in C/C++ world is the .h/.c(.cpp,.cxx,.cc,.c*) files. This is good becuase people using the class should not depend on the actual implementation, that could change in the future, so it is better if it's not shown directly on the screenm when the file is opened.

In fact I find easier to read a class that has no implementation details mixed in the definition, more members can fit in the same screen and they can even be organized in a functionality way. On the other hand, is easier to deal with only one file and not have to search for the implementation of a given file arround in a second file. All in all, for the people implementing a class, inlined definition is better, for people using the class separated is better, in my opinion at least.

Re:The subject of tabs vs spaces should be clear

[jamesh]

The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.

Linus has a knack for statements like that!

of the *.c files in the linux 2.6.15 source code...
total lines: 5118127 (including comments etc)
total lines with more than 3 tabs: 217129

So... the linux source code is approximately 4.24% screwed :)

Seriously though, use tabs and set them to whatever indent you want. That's the beauty of tabs.

Re:The subject of tabs vs spaces should be clear

[Soul-Burn666]

How about Java or C# where you write everything "inline".

In these cases, the seperation is made by having interfaces and classes implementing these interfaces.

Regardless of that, any modern text editor/IDE has context sensitive text folding, i.e something that reduces functions to definitions and code regions to title.

The 1960's called and want their text editor back!

[justasecond]

Holy-crap! Now I remember why I hated VI in my undergrad. days (20 years ago, but it seems nothing's changed). Lemme get this straight: "%" goes to the closing brace, "=" auto-indents, "==" auto-indents the current line, "" indents right, etc? Oh, and if I put "set sw=2" in my .vimrc file I get two-space indents when I press the Tab key? Of course! How obvious.

These days, only an overly-smug uber-nerd would use something so pointlessly obtuse.

Consistency is better than religion

[morrison]

For several large projects I work with where there are lots of developers, consistency of the source code is considerably more important than any particular developer's opinion on what the correct behavior of tabs and spaces are. These are projects where it is pretty much expected that there are or will at least eventually be developers that use both vi and emacs with zealotry as well a myriad of IDE environments. For at least vi and emacs, all source files utilize a local variables block that is understood by both editors in order to encourage a project-defined convention with consistent indentation:

/*
* Local Variables:
* mode: C
* tab-width: 8
* c-basic-offset: 4
* indent-tabs-mode: t
* End:
* ex: shiftwidth=4 tabstop=8
*/

With that comment block at the very end of all source files (whether they be C, C++, Tcl, Perl, Sh, SGML, etc), we do quite well in maintaining order and minimizing the indentation dispute. For the IDE environments, it at least gives them clear documentation on how to configure their IDE indentation preferences to match in every file. Maintaining a tabwidth/tabstop of 8 ensures consistent source display in most environments, including text printing and console display, leaving projects to simply define what offset/shiftwidth level they want for indentation. It can similarly still be tweaked for the projects that seem to insist on no tabs or want to match some IDE default religion.

Great Idea, But...

[The Stars Look Down]

Doesn't solve the problem at all. While his idea of lining up code that belongs together, e.g. code in an if-statement, is good, it doesn't address the fundamental problem of whether tabs or spaces should be used and how many characters/spaces should a tab/space use. One has to start indenting code before one can line up the rest of the code, so how does one start?

Re:The 1960's called and want their text editor ba

[Anonymous Coward]

Holy-crap! Now I remember why I hated VI in my undergrad. days (20 years ago, but it seems nothing's changed). Lemme get this straight: "%" goes to the closing brace, "=" auto-indents, "==" auto-indents the current line, "" indents right, etc? Oh, and if I put "set sw=2" in my .vimrc file I get two-space indents when I press the Tab key? Of course! How obvious.

That's like complaining heavy-duty industrial machinery isn't user friendly. If you need the power, something simpler and easier to use won't cut it.

These days, only an overly-smug uber-nerd would use something so pointlessly obtuse.

Yeah, and only a smug bastard would drive a dump-truck instead of a much easier to drive small car.

Anyone know of an editor that has this?

[WhatDoIKnow]

Brief

Don't mix em.

[Spudley]

I don't mind tabs. I don't mind spaces.

But God help you if you mix them together in the same program.

I've met editors that put four spaces for the first indent, then a tab for the second (removing the previous four spaces in the process). It was fine when you viewed the code in that particular editor, but open the same code in another editor with different tab stops, and it became practically unreadable. If they'd stuck with just tabs or just spaces it would have been fine, but nooooo.... some bright spark had to mix 'em together. Grrrrrrr.

(For what it's worth, the editor in question was LSE, on a VMS system. I don't know to this day whether that was the default setting or a setup made by someone at the company, but it caused a nightmare when we ported the system to Windows)

Re:Don't mix em.

[Anonymous Coward]

Just use a smart editor like Ultraedit and use the replace function :

Search for : " " (4 spaces)
Replace with : ^t (tab)

and you're all set.

Yeah, it's not a linux editor but it kicks ass :)

Re:Don't mix em.

[pe1chl]

I've met editors that put four spaces for the first indent, then a tab for the second (removing the previous four spaces in the process).

That is the correct behaviour when the indent level is set to 4 and the tabstops are set at 8-position intervals (which is the standard).
vi works the same way when you use Ctrl-T to indent. I think it is good.

it caused a nightmare when we ported the system to Windows

But that is only because editors and other textprocessing tools in Windows are so lacking. Any decent editor would be able to handle those files, and a simple filtering tool (like "pr") would have removed all tabs and converted them to spaces.
But not on Windows.

Re:The 1960's called and want their text editor ba

[justasecond]

I understand your point, but why do you consider "easy to use" and "powerful" to be incompatible?

This isn't the days of the PDP-11 -- there's more than enough cycles and megabytes to spare for running a nice, friendly text editor with a *sane* set of keybindings, *helpful* help text (none of the traditional *nix man nonsense, e.g., "the yank keystroke yanks text from the yank buffer") and easy customization (note: putting "SET SW=2" (crap, it's probably case-sensitive, so it should be "set sw=2", or is it "set sw = 2" ala bash scripting) is *not* easy customization, especially since that hack is probably only documented at the bottom of some completely inaccessible man page, if at all).

By the way, your analogy if flawed. If text editors are to be compared to heavy-duty industrial machinery, VI is a steam shovel. *Wood fired*.

Great, now we have a THIRD standard to fight over

[mad.frog]

Actually, this does sound superior to me over the first two (especially for something like Python where indentation is meaningful).

But if you thought we had holy wars now, just imagine the nightmare that a third option will introduce...

Re:The 1960's called and want their text editor ba

[jrockway]

> I understand your point, but why do you consider "easy to use" and "powerful" to be incompatible?

What's not "easy to use" about pressing one key to perform a complex operation. I'm no vi fan, but that sounds easy to me.

(emacs is M-x indent-region, or whatever you've bound that to.)

Re:The 1960's called and want their text editor ba

[msuarezalvarez]

there's more than enough cycles and megabytes to spare for running a nice, friendly text editor with a *sane* set of keybindings

One of the key things about vi(m)'s keybindings and commands is that they are extremely concise. I defy you to come up with a sane UI which allows the user to say "capitalize all a's, z's and t's that start words but are not followed by a digit, in the following thirteen lines".

Please note that I am not saying that it is easy to learn how to do that.

Re:No, No, It's Not the Length of the Tab!

[mad.frog]

Do you know how many times I've deleted one goddamn space only to have the whole line jump four or even EIGHT spaces over too far? Morons...

Do you know how many times I've tried to delete one goddamn tab-indentation only to find that some moron used a billion space characters to indent, making me hit backspace over and over where a single tap should have sufficed?

Fucktards.

There is no doubt about what is the right thing.

[Qbertino]

As far as I've come into contact with developers there never has been the slightest doupt what the right thing is. Tabs where introduced as the solution to this very problem. The only problem is that ancient vi and emacs aparently can't deal with them properly. Or their users sometimes are to lazy to set them up properly. The big problem is when experienced professionals follow suit with some blockheads and a few years later themselves insist on everybody using spaces at any time.
Why should everybody degrade the sourcecode because some dick on the team insists on using a 25 year old editor? Why should we be forced to use spaces in interpreted webapp languages because some webserver is to crappy to deal with tabs in the right manner? Unless there's some exotic situation - which I can't think of right now - that requires spaces to be used the stored source should be tabs. Then everyone can decide by himself how wide his indents are without bugging anybody else with his habbits. And if you're to fucking lazy to set up your vi or emacs properly to deal with the problem (either by back and forth conversion of tabs2spaces/spaces2tabs or by altering the display of code) and thus insist on the team following your whim you're nothing but a fucking assh*le. Get with the 3 millenium allready and get yourself a proper editor. There are enough around allready.

This whole discussion reminds me of 5 Million mindless dumb and stubborn outlook idiots establishing fullquote bloat and degrading email to something worse than AOL chat for everybody else, just because their mailer is so crappy.

Bottom line: The solution linked is a solution to a problem that doesn't exist because in a professional enviroment everyone can decide for themselves how their code is displayed, how large tabs are and if they're automatically converted into spaces if I want to use edlin.

P.S.: In the recent years, so I've heard, we even got a new problem popping up: People mixing spaces and tabs in the same sourcefile. Now there's a bunch that deserves to be shot at sight.

My 2 cents.

KATE indents groups of "if-else" (say) lines

[KWTm]

Speaking of tabs, something that I would absolutely love:
I want to be able to indent or unindent the opening statement for a given loop, be it int, sub, function, if, for or else, and have the entire section that it describes, including the braces, indent accordingly.
Anyone know of an editor that has this?

I don't know if this fits the bill, but KATE (KDE Advanced Text Editor) will indent blocks. Actually, it's the embedded editor in the KDE suite (for which KATE is the front end); I use the simpler KWrite and it does the same.

You can highlight a group of lines, and then indent or outdent using Tab or Shift-Tab.

If you want to indent an entire programming structure (such as a if-else structure) without having to specify the start and end of the block, you can use KATE's code-folding feature. It recognizes about sixty types of programming/markup languages based on the filename, and maps out the program structure in the margin (if you turn the feature on). For example, it marks the lines starting with "if {" and ending with "}" as a unit. You can collapse the unit into a single line, much like the outline feature of some editors, and you can highlight and indent the line as described above.

If it seems too protracted, you can always assign the operation to some macro key.

Re:A Tab is one character that represents 8 spaces

[caseih]

Correct. By convention, almost all character editors make tab stops by default to be every 8 characters. Therefore any indenting in your code should automatically use tab stops and then use spaces to fill in the white space that doesn't lie on a 8-character boundary. This is what I meant. Thus the whole idea of fudging with the tab stops and using code formatters to replace tabs with spaces is a poor idea, as you imply.

Exception to the rule.

[belg4mit]

Mmm, I don't think you can reformat brainfuck at will.

Re:Exception to the rule.

[Anonymous Coward]

gp wrote:

for any given language it is always possible to parse and reformat the code to ones liking

parent wrote:

Mmm, I don't think you can reformat brainfuck at will.

Nice try, but brainf*ck is whitespace agnostic. According to Wikipedia, "Brainfuck treats all characters but +-<>[],. as comments...". Perhaps you meant whitespace or make? :-)

In any case, it's obvious that the gp's "rule" was only intended to apply in contexts where the semantic meaning of whitespace does not vary with its representation. The tabs vs spaces discussion ceases to be a religious issue when substitution of one for the other leads to a different parse tree / execution outcome.

p.s. Anyone that programs in the whitespace programming language deserves what he/she gets when someone else comes along and reformats it :-)

Re:Exception to the rule.

[belg4mit]

I actually meant befunge, but neglected to double-check first.
Befunge source is a matrix.

>p.s. Anyone that programs in the whitespace programming language deserves
>what he/she gets when someone else comes along and reformats it :-)
An argument again' Python if I ever heard one :-P See also Acme::Bleach

Uh... ok...

[zizzo]

I read the article and played his demo. I'm not excited by this at all for 2 reasons: it invents yet another model of tab spacing and it encourages use of tabs.

Tabs just need to go away so we can get back to real debates, like CR vs. CR/LF vs. LF.

Nice, but not that practical

[ESqVIP]

The idea is neat, but it does not work so well in practice. He argues tabs have a single semantic meaning, but they'd actually have at least two distinct meanings:

1. Align this part of the line as a column — the heart of his proposal.
2. Push this line to the right — that's what normally happens when you use tabs on the beginning of a line on his demo;

Problem is: it's not always that easy to guess which behavior is the desired without either forcing the programmer to adhere to some new rules involving extra whitespace, or dropping the desired indenting completely.

For instance, the following examples don't work on his editor: (there's a "<TAB>" in there because I couldn't manage to make more than one consecutive space appear in that place)

public void DrawImage(Image image, Rectangle destRect, int srcX, int srcY,
                      int srcWidth, int srcHeight, GraphicsUnit srcUnit,
                      ImageAttributes imageAttrs, DrawImageAbort callback,
                      IntPtr callbackData);

if (x) {<TAB>/* security check */
    code;
}

Spaces

[I Like Pudding]

Dude, get the net. Spaces already won.

Why indent is not the answer

[istartedi]

I recall somebody here mentioning once that he worked at a place where CVS was setup to automaticly run indent on checkin and checkout. This seemed ideal to me--each coder would get to work in their own preferred style. Then I realized the problems it would cause with certain things. In most of my code, when I return an integer error, I use a macro that munges in a number for the file, a semantic error code (e.g., file not found) and--here's the problem--the __LINE__ directive. The beauty of this system is that since all the integers are compile-time constants, I get a lot of information in my error codes for no more runtime expense than returning something less informative (e.g., -1, or a simple EFOOBAR define).

The downside would be that if such errors were generated by sources compiled by different checkouts, with different styles, then reported errors won't match up on the same __LINE__. This could be resolved by eliminating the __LINE__ from the macro, but then you'd have to come up with a unique ID for each error, manually. That's tedious, miserable work. We could chose to have a single style for *compiling* the source as opposed to editing, but then you are right back to the same problem: there can be only one compiling/debugging style.

I guess, in lieu of __LINE__ I could use a manually enterred "random" number, and use a pre-processing stage to make sure that the number was unique--use the same number in the same file, and CPP fails, but this requires a hack to CPP.

FWIW, I use tabs becaues I figure that "presentation" is the editor's problem. I meant to tab in. If your editor is set to 8 spaces, that's your editor's problem, not mine. What's nasty is when stuff like MSVC converts tabs to spaces during copy-paste operations. My text has tabs in it. COPY-PASTE MY TEXT. DON'T CONVERT IT!!!

Of course then I end up with a "mixed" source code, and I can't tell what's happened unless I actually cursor back. Now, I know all you space guys are saying that if I just used 4 spaces I'd be fine, but then if my source is loaded by somebody who preferrs 2 spaces, or 8 spaces, they are SOL. They are slaved to my editor preference, and that's plainly wrong. In the long run, tabs are the only workable way to solve that problem, because they are, in a sense, "source" whereas spaces are the result you get when the text is "compiled" by the editor.

Re:Why indent is not the answer

[Anonymous Coward]

Doesn't the fact that you can't reformat at CVS checkin/checkout mean that your team must agree on common formatting conventions anyway? It shouldn't be much of a burden for a professional programmer to use the formatting conventions agreed in the team, or even dictated by the team leader. Adjusting to whatever tab interpretation your team leader subscribes to shouldn't be a problem.

Re:No, No, It's Not the Length of the Tab!

[MadMidnightBomber]

NEVER use tabs in code - or if you do, use an editor like jEdit that can automatically change them to spaces.

Or when you edit code and just have to change someone else's layout, do a find-replace on tabs with however number of spaces you want instead?

If you use a revision control system, you'll tend to find yourself pursued by mobs of programmers (with scythes, pitchforks and burning torches) for mucking up their diffs.

Re:A Tab is one character that represents 8 spaces

[jc42]

Yeah, except in the printing industry, where fixed-width fonts are nearly unknown. If you open random printed books, you'll find indents that range from 2 to 6 ens, depending entirely on the whims of the publisher.

The computer industry is a bit weird in its use of fixed-width fonts, which publishers usually find unaesthetic, but which are very useful to us computer geeks. But we do have word processor software that also default to variable-width fonts and indent by distance rather than chars. And CSS lets you define indentation by points or cm or other distance measures.

We should probably face a future in which most software also uses variable-width fonts, and the debate over how many characters to indent will be baffling to most users, because it sounds so nonsensical.

Re:A Tab is one character that represents 8 spaces

[Anonymous Coward]

"herefore any indenting in your code should automatically use tab stops and then use spaces to fill in the white space that doesn't lie on a 8-character boundary"

Utterly false!

I defy you to find probes of such an abomination!

Any sensible text editor (and to this point almost *all* text editors seem to be sensible enough) won't use spaces on a tab chain *ever*. A tab means "go to the next tab-stop" and only that. So if tab stops are every 8 chars and you are at column #23 a tab won't add a space, but will move you to column #24. If you are at column #25 it won't add 7 spaces, it just will move to column #32. If you change tab length, due to the fact that tabbing DOESN'T ADD SPACES, your editor will do the correct thing (where spaces added, your editor simply wouldn't know what to do, since it can't know it previous spaces were tab-paddind added or hand-added): it'll just go to "the next tab stop", wherever it currently is (and, by the way, that's the whole problem with spaces vs. tabs: the "inner tabbing", because changing the tab width will "jump" some inner tab stops from one point to the previous/next. All-lefty tabs are never a problem, only inner tabs are, and they can be resolved by using lefty tabs and inner spaces).

So...

(tab)function()
(tab)(tab)sentence(tab)//here a comment
(tab)(tab)longsentece(tab)//another comment

will deal to problems.
But...
(tab)function()
(tab)(tab)sentence()//here a comment
(tab)(tab)longsentece()//another comment ...will always align properly, no matter how width your tab stop is.

The proper tab length to use

[BlindRobin]

is 1.

Re:where you missed the point

[Anonymous Coward]

parent wrote:

The downside would be that if such errors were generated by sources compiled by different checkouts

I'll stop you right there and suggest you're not using a sufficiently "mature" development model. Anyone capable of checking out the code and compiling it himself is able to deal with the consequences it has upon the error numbers. The only builds customers should receive are those generated directly from the source tree; the generated binaries should include unique hashed identifiers that tell developers the exact build environment, so that when (not if) defects are reported, you'll be able to track down the problem.

build in indent

[POds]

Before veiwing any text documents, editors should have a optional transformation on startup, ripping away anything that doesn't conform to a users preference. For example, on c source files, the editor could run the text through a source formatter, presenting it to the user exactly the way he/she likes it to be set.

Then, who cares how things really are, we have our preference automatically assured!

This could perhaps be extended to changing between different spellings, I.e. Americanish => English.

Re:build in indent

[Anonymous Coward]

"This could perhaps be extended to changing between different spellings, I.e. Americanish => English."

first of all, computers aren't smart enough to do this. but even if they were, and if this proposition could make any sense whatsoever in some context, it would be useless for programming. just one example: for APIs, spelling matters.

programmer: text.setColour(RED);
compiler: set colour? colour? what the fuck are you talking about?

Re:where you missed the point

[istartedi]

Think again. Of course you have to enforce a consistant environment for releases; but then you are back to having "one indent to rule them all". I guess you could say that's an incentive for developers to not produce bugs, because if they produce a bug they have to debug it with the release settings, and if they don't like those settings it's more of a hassle. Generally though, we don't want to hassle people.

Re:There is no doubt about what is the right thing

[dwater]

> Bottom line: The solution linked is a solution to a problem that doesn't exist because in a professional enviroment everyone can decide for themselves how their code is displayed, how large tabs are and if they're automatically converted into spaces if I want to use edlin.

Really? In almost all professional environments I've known, such things as this are included in the coding standards for the company. IIRC, the width of an indentation has never been the same at any two companies...I always use VIM, and have it replace my tabs with spaces, so it's never been a problem - for me or anyone else (who's following the standards).

Re:No, No, It's Not the Length of the Tab!

[Schraegstrichpunkt]

At a company I worked for, the convention was to have "whitespace only" commits, and use those for fixing indentation problems (this was usually done by the QA guys). As for mucking up diffs, depending on the environment, it's not too difficult to get a whitespace-insensitive diff these days. (This is what was done at the aforementioned company.)

Re:No, No, It's Not the Length of the Tab!

[sodul]

That's why you want a good text editor. XCode is smart enough to backspace to the previous indent, deleting as many spaces as needed. I don't know about other text editors, I've tryed a bunch of them and always go back to XCode.

By the way anyone knows something better than XCode to edit Jam files ?

ConText

[cwernli]

The wonderfully lean and functional editor ConText uses "smart tabs" - the relevant option is active by default.

Note two things:
- it works like Word (i.e. with tabstops defined at certain positions, not with tabs defined as expanding to a certain number of spaces)
- only fixed-width-fonts are available (which is good, since it's a programmer's editor)

Re:No, No, It's Not the Length of the Tab!

[Chapter80]

Changing tabs to a number of spaces does not achieve what some original authors intend - that the tab means to skip to the next tab stop. On one line, this may mean skipping 1 space, and the next line it may mean skipping 7 spaces. So you can't do a find and replace! I think that's the point of the controversy!

Some people (or editors) think that tab = a certain number of spaces (which varies)
Some people (or editors) think that tab = skip to the next tab stop (which are spaced every X characters, and X varies).

So we have two issues to address - 1. Does Tab mean a certain number of spaces, or does tab mean to skip to a tab stop? 2. What is the value of X, (which may mean the number of spaces or distance between tab stops, depending on the answer to question 1.)?

Automatic word-wrapping

[Nurgled]

Once the editor's managing the tabs cleverly like that, I start to want crazy things like automatic wrapping in comments that respect the comment syntax. Imagine if the comment in ETNotepad's example was considered to be one long string of text and wrapped automatically to however many lines are necessary to avoid the comment running off the screen. This could also be extended to code if people are happy to make some consistent rules about how they wrap. I have some rules of thumb for line-wrapping which I think could be expressed in code, but I've seen some developers that just seem to make it up as they go along.

Re:Automatic word-wrapping

[Mr Bill]

vim can automatically handle wrapping in comments for you, as long as you have the proper filetype plugin loaded. This works for me when programming in perl using vim. You can even reformat an existing comment paragraph using the command gqap. That will automatically wrap all the lines at 78 columns (or whatever you have set), and reset all the comment markers at the start of the lines.

Fuel of the insightful type, courtesy of jwz

[ghmh]

The good thing about the web, is that 6 year old fuel is just as good as today's, and sometimes it even matures with age...

Here is jwz's not so recent, but totally relevant take on the issue: tabs-vs-spaces

Re:Fuel of the insightful type, courtesy of jwz

[Anonymous Coward]

jwz doesn't even know if vi uses tabstops. Also the argument against tabs is totally uncompelling - how does using spaces resolve the technical issues? Maybe different editors interpret the indent differently because the user has configured it to do so, because that is how they work most efficiently.
That's not something that needs to be fixed. By forcing your space indent settings on them you prevent them from working how they want to work.

Re:Fuel of the insightful type, courtesy of jwz

[bogado]

I don't agree, I believe that a tab character in a file should simply mean ident this line. This would help people in the, because it is an expected behaviour and the width of the the displayed tab can be configured. If I get a source code made following this advice it would show as the author likes not how I wished to see them.

If everyone see a file as they want, everyone would be satisfied, woudn't? I mean I believe that everyone actually uses some sort of auto-identation and the tab key when that fails, right? So in fact we have the editor program figuring out when we need an identation, and we correct him when he does some mistake. Why on earth the same editor makes things easier to others editors to figure out how to show the file???

Re:Fuel of the insightful type, courtesy of jwz

[jrumney]

how does using spaces resolve the technical issues?

It solves the technical issues because a space is always one character wide. Having different tab-width settings than other people on the same project causes problems when statements are split over multiple lines.

Famous last words

[Anonymous Coward]

Three levels of indentation ought to be enough for anyone.

--Linus Torvalds

VB have braces alright

[hummassa]

IF has THEN ELSE and ENDIF;
SUB has END;
FOR has TO DO and NEXT...
braces are not only {} () []

Re:No, No, It's Not the Length of the Tab!

[Master of Transhuman]

Use an editor that increases and decreases indents then - like jEdit.

Consistency *is* the religion

[Anonymous Coward]

The fundamental point of a rigourous (aka "religious") adherency to standards is to provide consistency.

The problem comes from other people adhering rigourously to other sets of standards, each camp being (consistantly) inconsistant with the other set of standards.

You've done a good job of defining the problem: you haven't solved it yet. People are the problem. The people who mix standards are going to be a problem in any religious camp: shooting them is a good first start to improving the programming world.

Re:The 1960's called and want their text editor ba

[IpalindromeI]

Please note that I am not saying that it is easy to learn how to do that.

It's not too tough once you learn the basics of substitution and ranges.

:s/\<\([azt]\)\d\@!/\u\1/g 13

new version out soon!

[Anonymous Coward]

According to his development blog, the author is working on a solution to some of the issues raised by this story.

You can see the blog and comment here and subscibe to the RSS feed here

Re:The 1960's called and want their text editor ba

[msuarezalvarez]

Heh. I knew that. What I wanted was, rather, that the parent poster show me how that would be doable with "sane" key-bindings and "sane" UI.

My Solution...

[GWBasic]

My solution: Just use the default setting of the IDE that everyone else uses! For Visual Studio .Net 2002 & 2003, the default was a tabbing solution that worked just like TFA describes.

In my first job out of college, no one ever argued about tabs vs. spaces because we all just stuck with Visual Studio's default settings.

Personally, I think code intenting is so obvious that I don't understand why we're still arguing about style. Just give me an IDE that indents automatically! I'd rather spend my time getting used to it then counting spaces.

Re:My Solution...

[Anonymous Coward]

I guess that's okay if you work in a monoculture, but at my company people use VIM, Emacs, Eclipse, Ultraedit - anything.

Besides, I like the idea that this system lets people use any font they like and any size of indentation they like without causing anyone else any problems...

Re:My Solution...

[Anonymous Coward]

"For Visual Studio .Net 2002 & 2003, the default was a tabbing solution that worked just like TFA describes."

Umm, no they don't. I've tried both of those versions of Visual Studio and they do not work in the same way as the article at all - they insert standard hard tabs and place tabstops every 4 (or 2 or 8 or whatever) characters across like every other editor!

Assuming coders only use spaces?

[bill_mcgonigle]

I want to see all the information that the author of the code was trying to communicate to me. This includes the positioning of text.

Which side of the argument are you coming down on then? Sometimes in my code I'm trying to communicate, "this should be indented to the fifth tab stop," and sometimes I'm trying to communicate, "this number should be over three spaces so the rightmost columns line up." So I have to use both whitespace types in different places.

I suppose the way to convey author presentation is to have him encode his editor settings in the source file. Somebody else here posted a de-facto standard for doing so. Anybody in either "camp" wishing the other one away isn't actually making any progress.

Re:Assuming coders only use spaces?

[Schraegstrichpunkt]

Which side of the argument are you coming down on then?

Whichever side satisfies that condition. From what I can tell, that means using ONLY tabs (i.e. no spaces for horizontal positioning ever) or spaces everywhre. Personally, I prefer spaces everywhere, since it's the least restrictive of those two options, and Vim's softtabstop setting lets me backspace them as if they were tabs.

As for "elastic tabstops", I haven't decided yet. If they become widely implemented in text editors (e.g. Vim, emacs, and I suppose TextPad), I could grow accustomed to them.

How about Syntax highlighting?

[bill_mcgonigle]

Also, your example of font size is irrelevant, since changing the size of a monospaced font is not a lossy operation.

How about syntax highlighting? I find sometimes that with highlighting a piece of code is easy to understand but with black-on-white text it's hard to tease out the logic or data structures.

So, isn't viewing code written in a highlighting editor in a non-highlighting editor or with other highlighting rules in effect a lossy operation? Do we start embedding highlighting rules in source code then?

Re:How about Syntax highlighting?

[Schraegstrichpunkt]

How about syntax highlighting? I find sometimes that with highlighting a piece of code is easy to understand but with black-on-white text it's hard to tease out the logic or data structures.

That's true.

Do we start embedding highlighting rules in source code then?

No, and you can imagine why not.

Actually, it's not such a bad idea, if implemented correctly. We could create a standard syntax-highlighting description format, and embed the unique identifier of the format in a comment (à la vim:set filetype=...).

"Tab" is short for "tabulate"

[p3d0]

You have it completely backward. Tabs are meant to make things line up. That is their purpose in life.