When developping in a large team, you have to make convention about the use of tab in source code. This article suggests a better solution: rather than saying that a tab character (a ‘hard tab’) will move the cursor until the cursor’s position is a multiple of N characters, we should say that a tab character is a delimiter between table cells. This has a nice side effect, since proportional fonts can now be used.
I started with a clean slate for my LoseThos operating system and decided to create a hard-space character where ASCII 31 used to be. I have a program which will convert all space eligable in source code to tabs. The hard-spaces go into string constants. Currently a tiny dot appears where hard spaces are, but it’s easy to make invisible.
Tabs are 8 columns and anybody who says otherwise is begging for a fight. You just have to be firm on defining what it is and there’s no problem.
variable width character fonts are for wussies. scientists and proghrammers are always dealing with tables and columns. Use PDF or something if you want to publish something.
I’m so sick of font, I made sure to include just one in my operating system–it’s a big waste of man hours fiddling with them.
http://www.losethos.com
I prefer to use spaces only, but where’s the problem if you use only tabs for indenting and set the tabsize according to personal taste? Works with proportional fonts as well.
Trouble only arrives when you mix spaces and tabs and I don’t see how those “elastic tabs” help with that.
compiles faster with tabs, for one thing
> compiles faster with tabs, for one thing
Same as saying “my car runs faster when I don’t wear underwears” :]
Or install a real editor that can convert spaces to tabs and vice-versa. I prefer tabs by the way. The problem is many people at the forefront of the tabs vs spaces arguments are just ill-informed. On most operatings system, a tab width of one point corresponds exactly to a space. The only difference is that a tab represents one character which, saves text editor from counting several space characters as opposed to one tab character among other annoying text processing issues (automatic indentation for example) that plague editors that have to proccess spaces as indentation delimiters. In a perfect world, tabs should be used for indentation, because that’s the purpose for which it is created. However, some people insist of making life miserable to text editor developers. 🙂
Edited 2006-07-04 13:05
such as?
My editor Scribes does that. I believe VIM and Emacs also have such capabilities. Not many editors have the functionality but good ones do.
I’ll put that on my todo list. Not very hard, unless it’s context sensative.
The key is to ensure one tab point corresponds exactly to one space character, like most operating system do these days. That way the tab vs spaces argument essentially becomes a moot point. Because a tab will just be a bunch of spaces representing one character.
you seem confused
It’s a confusing issue for most people, otherwise we wouldn’t be having the pointless debate. A single point width of this “t” character is the same as this ” ” (one space), on most operating systems. Most applications allow you to customize the width of the “t” character. So if you change the “t” width to 4, it will correspond to exactly ” ” (i.e 4 spaces) this much space in your application. The observant person would soon realize that tabs are spaces that represent one character. So the tabs vs spaces argument is pointless. It like arguing about whether sliced or unslice bread is better. There are other debates that demand more attention like the different newline characters for different operating systems.
PS. OSNEWS mangles the space and tab characters so they are not properly represented. Is there any chance of supporting the pre and code html tags in the future? I mean even blogs allow you to use them these days.
Edited 2006-07-04 13:53
Add jEdit to the list of editors capable of spaces <–> tabs conversions
(edit -> indent -> Spaces to Tabs / Tabs to Spaces)
Very nifty feature, indeed.
With a good editor conversion of tabs into spaces and vice versa is just one keystroke.
As long as you don’t need to align items on a line (just the lines themselves) then it doesn’t matter if you use tabs or spaces. The only difference is that different people prefer different indent width, so therefore tabs are preferable since they are easy to adjust in the editor.
Just never mix tab and spaces when indenting! Different people and different editors will have different tab sizes, so if you mix tabs and spaces you’re just asking for trouble without gaining anything.
Anyway, I would prefer if the editor would work more like a normal word processor. E.g., it shouldn’t let me put the cursor at col 0 on a line that is indented to col 8. Editors are smart enough to indent correctly on-the-fly, and I see no reason to place the cursor before the beginning of the line or after the end of it. Then the editor could also display the code with user-specified table-based alignment and indention (or whatever) regardless of what align/indent style (spaces/tabs/mixed) the file has. (Ugh.. although being quite simple, this is surprisingly difficult to explain… or maybe I’m just bad at explaining things.)
The problem is people change the width. In the old days it was 8 characters on VT100 terminals and stuff. You need to madate it and get rid of the confusion. I happen to indent 2 spaces per level in my code, but I still keep 8 character tabs. Some people want one tab per level of indention. That creates the confusion.
oops. I explained it bad too!! This is hard to explain. I used “character” when I meant the position on the screen for one letter.
I’m a 2 spaces per level of code guy as well – comes from the first ‘high level’ language I dealt with being of the Wirth family.
The last place I did a large scale coding at, we all have different ideas about what the spacing of a tab should be – Instead of that arguement actually meaning anything, our boss just said ‘everyone has to use tabs, no spacing for indents – one and only one tab per ‘indent’ – set your editors to what you are comfortable with – so long as you all use the tab in the same way, what does the spacing even MATTER?
Seriously, just because the DOS user wants five space, the Wirth programmer wants two, and the old school Unix guy wants three while the new school *nix folks want eight, WHAT DOES IT MATTER if you only indent once per ‘block’ area? So long as each persons editor is set to what they like, it should make ZERO difference one way or the other.
what a waste–one character for 2 spaces–hardly worth it. Problem is people get clever adding features, like variable tab widths and screw things up. Less is more quite often. I can’t stand html–fubar–always fighting with it. Document should be how the author wanted it. People must learn to adjust to different appearances of code–comes with experience.
case in point–what do you do about function headers where you have lots of parameters–will get all messed-up fiddling with tab widths
If you’re meaning a function prototype where the parameter list is so long that it covers multiple lines, I’m of the opinion that this is something that’s best handled with some pretty-printing features in the editor. XCode’s default editor automagically arranges all that stuff nicely, and I can’t imagine that it would be too hard to add to any editor that already has some synax-highlighting and auto-formatting features.
It’s certainly easier to modify a text editor than it is to resolve an age-old holy war like the tabs vs. spaces one.
The problem is aligning lines corresponding to a single statement. For instance…
int main()
{
call_me(foo, bar,
baz, biz);
return 0;
}
You have to mix spaces and tabs to align the “baz, biz);” part, otherwise you will get instant misalignment when something else chooses to look at your code with a different size for the tab character.
This is why I use spaces for indentation: I get reliable results everywhere and I don’t have to mix them with tabs.
Of course I follow other people’s choice when modifying their code…
PS: osnews munches spaces, and shows “nbsp” literally… annoying.
Edited 2006-07-04 14:32
I conceed a point–I’d prefer no tabs and just spaces to variable-width fonts. One advantage to no tabs is mindlessly moving the cursor. I take pride, however, that my kernel compiles in 0.41 seconds when in disk cache. (My benchmark is to measure the compiler, not the hard-disk hardware)
> call_me(foo, bar,
> baz, biz);
> […]
> You have to mix spaces and tabs to align the “baz, biz);”
> part, otherwise you will get instant misalignment when
> something else chooses to look at your code with a different
> size for the tab character.
No, you’re wrong. Line indenting is not the same as term alignment. It doesn’t matter if you use tabs or spaces when indenting, the lines won’t become misaligned when changing tab size. However, if you want to align parameters/values/whatever then you have to use spaces and even then it only works if you use a monowidth font.
Edited 2006-07-04 15:32
You are missing my point… In real code we have both line indenting and term alignment.
In a all-spaces environment things tend to always go smooth, but when tabs are added into the mix, we get tabs for line indenting, and then spaces for term alignment.
Since tabs and spaces are visually indistinguishable, eventually you will get extra tabs in term alignments and then the “tabs allow the programmer to choose his own tab stop value and still have proper indented code” argument becomes invalid…
There are two ways to deal with this:
1) Use a text editor that has a “show whitespace” function to spot tabs and spaces (which sucks);
2) Use all spaces and forget about the whole problem.
And I think than the proper indentation is the one the original author chooses, so…
> Since tabs and spaces are visually indistinguishable,
> eventually you will get extra tabs in term alignments
How so? I certainly won’t put any tabs in my term alignments. First of all it’s the editor that’s supposed to put all tabs/spaces in the right places. Second, even if you use a “dumb” editor it still probably supports auto-indenting and then you’ll just do your alignment. And even if the editor wouldn’t support any auto-indenting it’d still be just as easy not to accidentally use tab when aligning, regardless of what you indent with.
On the other hand, indenting with spaces makes it easy to do off-by-one errors. Countless times have I seen code with an indention of 4 (i.e., 4, 8, 12, …) spaces, and then a few lines that are indented 9 or 7 spaces. Even if the editor auto-indents these mistakes are quite common, at least among people I’ve worked with.
Are they honestly resuggesting the tabstop? The ORIGINAL SOLUTION TO THIS PROBLEM as something new?
Editors like Emacs have done tabs this way for, well, forever by default.
It’s as simple as that.
Please read this excellent article:
http://electroly.com/mt/archives/000002.html
Couldn’t explain it better myself.
Hey! spaces does solve the issue of function headers, but doesn’t solve the issue of converting unwanted spaces to tabs automatically, unless the conversion parses the code. This emacs, thing… is it context sensative to code? variable-width fonts still stink.
This emacs, thing… is it context sensative to code?
Yes.
All major Java IDE’s (IDEA, Eclipse, Netbeans etc.) has tab emulation with spaces and smart indentation and automatic code formatting. You can convert vice-versa. what is the big deal?
It’s not a big deal. People just like to argue over minutiae.
Repeat after me: Tabs are 8 characters.
When you email code you want it to look as was intended.
Same when you print code.
Aligning code such as
foo(arg1, arg2,
arg3, arg4)
with tabs will always yield different results.
To avoid all kinds of problems, use spaces.
> Repeat after me: Tabs are 8 characters.
I always use tabs, not spaces.
Mainly because tabs are faster to type and to navigate.
Also they are more compact.
> To avoid all kinds of problems, use spaces
I using tab=8 in asm and tab=4 in c-like languages
and so does everyone in our company. So we don’t have any problems
I work in a shop that has two macromedia dreamweaver
users, two vi users, and I’m using vi and jEdit.
The code that passes under my editor often looks like
it was spaced out by comittee. The worst part is that
there are files with regions that are tabified and
files where regions are spaced. The formatting often
breaks down when you start putting tabs in the middle
of lines, to line up a column of equal signs.
I typically just ^a, right-click–>tabs to spaces and
re-block those sections of code that are mysteriously
indented 50 spaces for no reason.
I use vi A LOT–I’ve got no real complaints about it.
However, when I come across python scripts that have
both tabs AND spaces in them, I quit vi and go right to
jEdit becuase I need to be able to spot those tabs
and clean up the alignment so that script will get back to running.
My vimrc looks like
:set et
:set tabstop=4
One jEdit plugin I liked quite a lot when doing java
was the jalopy plugin, which could re-indent your code
and brace alignment. I’d like a jalopy for PHP code.
You can use
:set list
in vim (not sure for vi) to see tabs (they are showed as ^I by default) and end of lines ($).
You can set, which character to show for eol, tab, trailing spaces, … with
:set listchars
Just type
:help ‘listchars’
in vim to see what can be set.
Having developed a Mac Text editer decades ago, I feel both ways, tabbies are a pest on the user and on the developer side. I also vote for 2pt (pascal again) tabs, can live with 3pt, but when the tabnazis tell me to use theirs, I get ever so twitchy.
Its not just software, most hardware is designed these days in HDLs not so different from C…
Tabs cause issues with the text editer munger code, basically tabs!=1space means we already have sort of proportional fonts, 1 space or not 1 space wide even though the engine tries to equate memory line size with line width. And what happens when you mix tabs after text, more rules to figure the placement, widths.
For real programming, I would never want to use pro fonts for the code source, but I could certainly use them for the comments and paragraph docs, ie mixing 2 similar size fonts.
Then we get into the issue of embedding source code back into documentation with pro fonts, its usually another mess again. I had trouble with OpenOffice trying to include fixed font code blocks, turns out some chars in fixed font were not fixed at all.
Personally I think we need to move onto editing with a mix of fixed and pro fonts and the tool should understand the reasons for this and not get in the way. Not sure what editers out there are good at that.
One issue with text editers is that they must always be able to open potentially huge machine generated files usually no tabs, such would kill most proportional word wrapping engines.
I rather enjoyed reading the LCC compiler sources in the Hanson book which was machine readable from within a book, in fact I guess one could write the docs in a real book writing tool and insert code and still be able to export the code separately.
FWIW there was atleast one language (occam) where the tab was part of the language spec, instead of using {..} to mark blocks, you had to use tabs to position sub blocks, if you got the position wrong, the meaning changed. Not sure if the tabs were spaces or actual tabs.
is to hand this guy a copy of emacs. 99 times out of a hundred, when I hit the “tab” key under emacs, I get the desired result. In addition, the block matching is a huge timesaver.
I have no desire for proportional fonts in my source code. It’s not necessary. I can see the need for unicode support, but as far as I know, unicode isn’t supported by most of the compilers out there.
I’ll give him credit for an interesting idea, but so far, it looks like a classic example of a solution in search of a problem.
The American Standard for Computer Information Interchange was originally designed as an encoding meant to mimic the behavior of mono-spaced typewriters when sending text to a remote typewriter called a teletype. As such, tab is not a character. Rather, it is an inline instruction for the remote typewriter. The same is true about many of the ASCII ‘characters’, such as backspace, space, carriage return, and line feed.
The original meaning of tab was exactly the same as the tab key on a mono-spaced typewriter: move the typing position to the next tab stop.
Originally, tab stop setting were variable and controlled by the operator. One could, for example, set tab stops at the 6th, 7th, and 73nd line position (for Fortran, say) or at a different set of positions for Cobol, or at a third set for writing formal letters.
Also, the machines had default tab settings: a tab stop at every eighth line position.
The problem was that computers are flexible and, especially in the days before widespread networking, programmers working in isolation modified the way tabs worked in their display programs in different ways.
So, the “issue” with tab stops isn’t what’s convenient for your editor, or even how to arrange things so it’s easy to retain apparent vertical alignment between our editors, but rather, how to retain apparent vertical alignment between our editors, any programs we use to pretty print, the compiler’s output listings (if we use such a compiler), SCM file comparison tools, any other code extraction tools, any various printer software.
The solution is for a given project to adopt exactly one way to do indentation and stick to it. That’s not hard. But people wish to do it ‘their way’ rather than the team way. It sucks to be human.
(The “right” way, by the way, is to leave tab stops at 8, because you have to cope with all the printing and pretty-printing software that naively assumes they are, to use one-tab-per-level to represent block indentation, to use N-tab/enough-space indentation to handle internal alignment, and to live with it. — unless you’re in a position to modify all the tools around your shop to use the same rules for indenting, then you can change ‘8’ to whatever.)
“Repeat after me: Tabs are 8 characters.”
No, a tab is one character, or to be more correct, it’s an instruction represented by one character. How it is then represented on screen is something entirely different.
Btw, tabs are better than spaces. So there.
Edited 2006-07-05 04:31
It seems to me that this is the exact same problem we went thorught with HTML and every other textual communication format.
The sollution in all cases appears to be to seperate semantic from layout.
I mean it isn’t just tab vs. space that differ in taste. Such things as ‘{‘ on a new line or not, ‘}’ indented or not are examples of other formating issues.
So, what would it take to seperate semantics from layout in a program description format?
> The sollution in all cases appears to be to seperate semantic
> from layout.
Yes! That is part of what I was trying to explain at the bottom in this post: http://www.osnews.com/permalink.php?news_id=15087&comment_id=140174
It shouldn’t matter much what conventions the underlying text file has, the editor should still use user-specified layout when displaying the code.
Why do people even bother with tabs? Spaces are always the same width. Always. They always mean the same thing in every editor. You like to use the tab button? Then program your editor to insert 4 (or however many) spaces for a tab.
People that are still trying to find “solutions” to the tab vs spaces “problem” need to find better things to do with their time.
Tabs are useful for a number of things. Writing source code isn’t one of them.
> Why do people even bother with tabs? Spaces are always the same
> width. Always.
A Space has no width. It’s a character. Glyphs have widths, characters not. BTW the width of glyphs should be irrelevant to programming unless you are trying to output ASCII arts.
> They always mean the same thing in every editor.
Yes, they mean a space. When I want to indent a line of code, I don’t mean “put 4 spaces there”, I mean “indent that stuff”. Tab is more like that. When I want to align something, I don’t mean spaces nor tabs, I mean “align that stuff”. Neither spaces nor tabs do that right.
> You like to use the tab button? Then program your editor to insert 4
> (or however many) spaces for a tab.
Why, if that’s not what I want it to do?
It’s about time everybody quit using VT100 terminal’s ASCII to represent their code and used a convention that’s built into every web browser and most GUIs. This solution is a great example of code reuse considering that fact.
The programs written to take advantage of this fact are listed in the article linked in the news item and it’s a pity there are so few of them.
HTML is not applicable to every environment. I work in both synchronous (UTS) and asynchronous (VT) terminal environments and maintain software which creates and parses text displays which could appear on either one, or in something completely different from either. Who knows what every airline around the world uses? HTML is far too fancy (and makes far too many assumptions) for our needs.
…tabs are simply not allowed in source files.
That makes the argument a lot easier to manage. Code indentation is done using spaces. Period. 🙂