Indention - why spaces?

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

Russ Allbery ([email protected])             <http://www.eyrie.org/~eagle/>

Quouting from that page:
That ensures that, even if I happened to insert a literal tab in the file by hand (or if someone else did when editing this file earlier), those tabs get expanded to spaces when I save.

If you are using a source management system, pretty much *any* source management system, doing this will cause all the lines to be "rewritten" if they had tabs. The fact that this person would advocate changing code that they didn't actually change shows a distinct lack of clue. No engineer who works for an even semi-pro company would dream of doing this. At BitMover, anyone who seriously advocated this for more than a day would be fired.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

well, he DID work at netscape...

j.

toyota power: http://indigoid.net/

Yeah, that recommendation always bugged me too. I would never do that; if you really want to enforce something like that, the proper place is in a pre-checkin transform in your source management system so that everything that actually hits the source management database has no tabs in it. Not in individual editors.

But the rest of the message is a good summary of the issues, as far as I'm concerned.

I'll add one additional issue, and the one that bugs me the most in practice about tabs. Tabs make patches a pain in the neck to read, because they change the indentation of the lines in a diff so that it no longer matches the original indentation. In particularly pathological cases, they can even make an indented line even with an unintended line.

Russ Allbery ([email protected])             <http://www.eyrie.org/~eagle/>

Disagreeing with that slightly - there is middle ground, but it needs to be explicit, or at least source file type dependent. For example, whitespace on the *end* of a line containing text can almost always be stripped. I've had far more trouble than its worth of designers submitting code that accidentally included whitespace at the end of lines. They didn't even *intend* to change the line, or when they made a change, and restored the original code, they unintentionally left whitespace on the end. Later on in the development process, this seemingly insignificant difference becomes significant when two functional equivalent lines trigger to the source manager as segment that requires a complex merge operation.

The middle ground takes the form 'this is a common mistake people make for this specific project, and as a business case, it makes a lot more sense to quietly handle the situation automatically.' Some design groups force their source to be put through a mandatory automatic code beautification/styler process during submission. As the customer, and as the people directly familiar with the problems they experience, and the responsibility for their choice, they *should* have the choice to enable a process such as is described in the above URL (expanding leading tabs to whitespace on submission).

The alternative, of course, is the choice that Linux takes. If it doesn't meet the appropriate requirements, it doesn't get submitted.

The source manager is supposed to help you, not hinder you. For very common situations, where responsibility for consequences can be accepted, the source manager *should* provide the means to perform transformations of the source code upon submission.

Firing an employee for suggesting this seems a little extreme... :-)

mark

[email protected]/[email protected]/[email protected] __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

Well, I disagree: http://www.wiggy.net/rants/tabsvsspaces.xhtml

Wichert.

Wichert Akkerman <[email protected]>           http://www.wiggy.net/
A random hacker

In my opinion, indentation in any form is irritating.

I find a left hand margin that jumps around, and in deeply nested loops effectively makes a 132 column terminal in to an 80 column terminal, completely pointless.

Overall, it doesn't help me to follow the program flow at all, if I have to scroll excessively just to see lines that would be visible without scrolling if only there were not ~40 blank columns on the left hand side of the terminal.

John.

So set your tabwidth/shiftwidth/whatever to 0 (or 1, at least vim does not seem to allow you to set a zero shiftwidth).

Well, I disagree. But I agree that the amount of indenting used is a highly personal thing, and I find forcing a set limit by demanding people use spaces a bad practice. But I don't do any kernel work, so my opinion is probably of little value here.

Wichert.

Wichert Akkerman <[email protected]>           http://www.wiggy.net/
A random hacker

Code like that definately should be indented. Preferably 6 foot down.

Rik

Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://guru.conectiva.com/
Current spamtrap:  <a href=mailto:"[email protected]">[email protected]</a>

I disagree. Negative tab indentation (where you start off on the right hand side of the screen and tab or space towards the left) is obviously the most natural form. We should all be using it - it'll make the kernel source _lots_ more readable. In fact, I'll start converting the kernel sources now. ;-)

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

The devfs source code is --> that way.

Dave

| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

<quote who="Dave Jones">

IMHO and in my personal projects I use the following indenting rules:

1) use TABs for _indentation_
2) use SPACEs for aligning

here is an exaple:

<tab><tab>if (cond) {
<tab><tab><tab>dosometing; <tab><tab><tab>printf("This is foo: '%s', and this bar: '%d'",
<tab><tab><tab> foo, bar);

where tabs are explicitated, while spaces not.

I think this way combines both tab and spaces advantages, allowing each coder to have its own indentation width, but NEVER destroing the aspect of the code.

This is only my opinion :-P

Emiliano 'AlberT' Gabrielli

dip. di Fisica
2° Università di Roma "Tor Vergata"

Em Mon, Dec 30, 2002 at 07:53:22PM +0100, Emiliano Gabrielli escreveu:

I second that.

- Arnaldo

This problem is as old as the typewriter itself. The trouble is that a Tab character doesn't have a fixed size - some set it to 3 characters wide, some to 4 some to 8, or whatever.

The 'indent' program was written a couple of decades ago, to pretty print C code. It has a 'GNU' standard, but I'm not aware of a 'Linux' standard. Anyhoo, the only way to prevent indentation wars is to use spaces, not tabs and to set 'diff' to ignore white space when comparing files...

------------------------------------------------------------------------
Herman Oosthuysen
B.Eng.(E), Member of IEEE
Wireless Networks Inc.
http://www.WirelessNetworksInc.com
E-mail: [email protected]
Phone: 1.403.569-5687, Fax: 1.403.235-3965
------------------------------------------------------------------------

I think the previously proposed solution solves the issues you raised.

With the proposed solution, that doesn't matter.

Why not use tabs and spaces like proposed and let everyone see the file the way they want to?

--Zac

hi,

Anyhow, sorry, i really can't understand that. What could be more "indention war preventing" that letting everybody use his own indention width?

There are two main aspects of *not* using tabs:
- editors mess them up. but: use an *editor*. not a word processor. kernel source's line endings are \n, not \r\n. some (windows) editors mess them up. and nobody cares (and that's ok that way. nobody WANTS to use an editor which messes up so simple things). some editors don't show tabs. well. this leads to a mixup of tabs <-> spaces. but if you really fear about this, just use an editor which supports showing tabs. joe doesn't show spaces (by default?), but i never missed that, for example.
- aligning. well, just use spaces for aligning, tabs for indention. two different things. two different characters.

TAB characters simply *have* no assigned width. that's the reason for them. they are not a macro for 3/4/8 spaces.

not using spaces, in my eyes, just *takes* a possibility to platform-independant format sourcecode on the given screensize. it gives you nothing.

and as they might be some pitfalls (wrong aligning etc.), you can still set the tabwidth to the one of the author. in that case, you didn't win anything by using tabs, but you didn't loose either.

again, i was just *wondering* why everybody is using spaces, and still, i can't find a good reason for that. if anybody shows me that, i'll maybe start using spaces (again).

felix

If everybody had exclusive ownership of code sections, and only they ever made changes to that code in the time before, now, and after, than nothing.

In the more practical world, and especially for code architects, or senior programmers, every user touches every other users code.

If they each adjusted their style to match the code they were editting, this would be an unacceptable overhead. If they each casually adjusted the style of the code to their own style and editor setting, the code becomes a mess (different styles of indentation used within the same function body, etc.). Also, they become tempted to indent the surrounding code to their style (even if this introduces whitespace only changes into the code stream) as their style may conflict.

Style should be determined per product, or at least per component. I would say style should be determined universally, but that would not be practical, nor would it encourage creativity.

mark

[email protected]/[email protected]/[email protected] __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

[...]

There is a contradiction there. In reality you learn to deal with different indenting styles, especially if you live in an free software environment. Style should be consistent within a product though.

Wichert.

Wichert Akkerman <[email protected]>           http://www.wiggy.net/
A random hacker

Well, that is the problem - trying to figure out what the tab size of the author was. It gets messy really quickly when a file was edited by multiple authors, using multiple tab widths. It then becomes impossible to figure out how to set the tab width to make the code indent properly.

Anyhoo, over the years, I learned not to care about it, since it is just too trivial an issue and there are more important things to worry about.

So, if I find a page's indentation bothersome, I run it through 'indent' for a private readable copy. I even ported 'indent' to windoze a couple of years ago...

indent itself dosen't have a 'Linux standard' BUT .../linux/scripts/Lindent is there to get things right (in terms of CodingStyle)

I don't know if is usinging it or even if it is still current but it's a starting point.

Yours Tony

Jan 22-25 2003 Linux.Conf.AU http://linux.conf.au/
The Australian Linux Technical Conference!

Unless you don't use GNU indent but an indent that's written in a sane codingstyle itself, like:

	http://developer.berlios.de/project/?group_id=192

BTW, this practice is codified in Solaris developer's guidelines. They even have a perl script called "hdrchk" which is run before commits and tells about violations. Actually, the Sun requirement is to have exactly 4 spaces, but it sounds a little too anal to me.

-- Pete

Indeed and the reasoning is that tabs are for indentation, 4 spaces are for continuation lines.

	if (expr) {
		statement;
		statement;
		if (really_long_expression && another_expression &&
		    one_more) {
		    	statement;
		}
	}

You can do slightly better than that if you do it like this:

		if (really_long_expression &&
		    another_expression && one_more) {
		    	statement;
		}

I try and get people to put the longer part of the expression on the continuation line, your eyes will parse that better than the first way.

By the way, this sort of thing is a big deal around here, I spend a lot of time getting people to do it all the same way. It's worth it.

The bottom line is "can I fix bugs in your code quickly?". Indentation is part of understanding the code.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

And I agree with your disagreement. And it's useful to compare your rant with his rant side by side, just looking at that I can guess I'd rather fix bugs in your code than his.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm