Most of the author's points are easily avoided if you learn how to read other people's code.
Srsly. When you're starting a brand new green-field project, you can indent however you feel like. But if you're working on an existing project, just do it the way the original person did it, even if it's not your favorite coding style. It's not worth the time and energy arguing over it. All this talk about ease of reformatting code is ridiculous...you shouldn't reformat code, you should just do what everybody else on the project does.
Every version control system I've ever used would put a change to every line of the file in its history. It would be possible to retrieve all those changes and then filter out the ones that I don't care about, but that's so expensive that I've never seen it as a built-in feature.
Exactly. This is almost common sense; I have never specifically told anyone "to commit to my repository, make sure you indent in such-and-such way". I have also never been told this rule; if I notice that every indentation level is two spaces more than the last level, I assume I should do the same. (If it's a whole project, I just add the changed settings to my .eproject file, and never think about it again. Very simple.)
I have found, in general, that it's the very new or very bad programmers that want to quibble over style. Everyone I've worked with is fine with anything. In the long run, it just doesn't matter at all.
The rules is somewhat common sense. But I have had to tell people the rule (mostly to very new programmers). Interestingly I haven't found that they wanted to quibble about style, they just didn't notice they were doing things differently.
Putting the correct thing in their .emacs usually clears things up (show-trailing-whitespace throws your loose whitespace habits right in your face).
According to this person, KWrite is better than Emacs and Emacs is a bug. In my opinion, this makes his post a little less credible. The rules that he suggests we all learn for how to use tabs and spaces in a file are helpful, but only when you're forced to use tabs. Otherwise, using spaces is always easier when you have to share your code with people that are not required to use KWrite.
I personally use kwrite. That doesn't mean it's "better" than emacs, just that I prefer it. Editor use is an indiviual choice, and people are more productive when using the editor of their choice.
Similarly, people are more productive when using the indentation style of their choice. I like 3 or 4 spaces of indenting, and I find using 8 spaces makes the code hard to read. Other people have different preferences. It seems to me that the best way to accomodate everyone on a multiple-developer project is to require that code is run through a formatting utility before being checked in, and to allow people to use similar utilities to format it when checking it out and editting it.
"Why I'd like to rehash the same tired old arguments people have been making ever since we first got the '\t' character" would be a more accurate title.
Decent editors do automatic indentation anyway of course, but there are often circumstances (especially in Perl, where even GNU emacs can't always parse the syntax correctly) when they don't do the right thing.
I have been working on cperl-mode's indentation recently, and think it gets indentation right in 99.9% of cases. If you encounter that 0.1% case, you should submit a bug report here:
I really dont see the big deal. This is simple stuff and we are programmers. It is obvious that a standard is the easiest and safest way to go wheather its 2 tabs , 1 space , 1 tab... etc. But are people really having that many problems? It is annoying to see tabs and spaces used in the same file and unclean code but is it that bad? Who is programming with you to the point where their tabs/spaces actually makes your code unreadable (dont count html which really needs correct indentation to read). Has anyone ever had a huge bug created by indentation?
Spaces are fine, tabs are fine, but mix them together (for indentation) and you're asking for trouble. That's all I've ever had to think about the subject. Personally I consider two-space indentation to be the One True Way, and my tab key is setup to physically insert two actual spaces.
Greedy backspace. I use vim, and it's actually pretty smart about it; most of the time it kills two spaces when that's what I want, and only one space when that's what I want.
The author of the article actually demands mixing them. He says that you should never use tabs to do things like format a block of text -- that's what spaces are for.
So this guy isn't pro-tab-only. He's in favor of mixing.
I've been using ':set list' in vim with different characters for spaces and tabs ('_', '| ') appearing at the start of a line for the better part of a year now. This makes sure that I stick to the convention of whatever project I'm working on because it's very obvious when I don't.
I agree with the article's rationale and use this practice for new projects. Nearly all the arguments I hear for spaces are 'Other people screw it up, so just go with spaces to accommodate them'. I think this is quite defeatist. Why not enforce the coding style of choice for a project with some check-in hooks?
I think the main issue is just that on a given project, there needs to be agreement on what will be used. I hate opening up a file in vim and seeing some lines tabbed and some lines spaced and things not lining up right at all.
Not a terrible article, although I was a little put off by the "K&R Style is obsolete" remark, considering that a lot of the projects I work on use a slight variant of K&R, the Linux kernel included.
I first heard of this technique a long time ago--it made sense then and it makes sense now. But for it to be actually usable it would need some good editor support (I'm not about to micro-manage my editor and alternate between spaces and tabs manually). I would love to see some Emacs code that integrates with c-mode and perl mode. Short of that I have to say banning tabs completely from your source is the only way to make it look consistent across editors.
Emacs does what the author wants out of the box, I think. It indents with tabs until that is no longer possible, then it switches to spaces. I don't really see what this buys anyone (except confusion), so I disable it and only use spaces.
This article did not convince me to change my mind. (It did convince me that the author knows nothing about Emacs, like most Vim users.)
What you describe is not what the author (and I) want. You should not use tabs until it is no longer possible, you should only use tabs to indicate the indentation level. To perform further alignment beyond the indentation, for example to align arguments to a function after the opening parenthesis you use spaces.
Which will no longer align if tabstops are changed.
I've set up emacs to do the right thing in c-mode, and possibly in other modes which inherit from it. It's not hard to find a solution online, but it's certainly not "out of the box".
I use `:tabstop=2` in vim, and whenever I load the java library source files, the indentation is mucked up: they mix space and tabs (`:ts=8` fixes it). I'm guessing this a common (?)
I use tabs mainly from habit, but I think it helps keep consistent indentation (it's quite easy to be off by one space). Also, with my habit of using `h` and `l` for navigation, tabs mean fewer keypresses than spaces (I should use `w` and `e` I guess)
Am I the only person who finds these arguments childish? Why can't people just respect whatever style the original author chose?
Also one of the best things you can can do to help avoid a lot of this frustration, is put those comments at the end of every source code file that configure indents for both emacs and vim. It makes switching between 4 and 8 space indents a bit less irritating.
Ah, one assumption I never like in this discussion: code will always be read via an editor.
I've been flirting around with a literate programming environment, and it's been far easier to use spaces with a traditional line measure - around 80 chars. The code can be included into HTML or print layouts with few edits. That seems to be the "easy to layout" setup.
Saying you can define tabs to be a different number of spaces is, at least some of the time, erroneous, because some languages (e.g. Python) define tab as 8 spaces.
I have a very simple policy on tabs: I don't use them. And since I've had that policy, I've never had a problem involving tabs.
Srsly. When you're starting a brand new green-field project, you can indent however you feel like. But if you're working on an existing project, just do it the way the original person did it, even if it's not your favorite coding style. It's not worth the time and energy arguing over it. All this talk about ease of reformatting code is ridiculous...you shouldn't reformat code, you should just do what everybody else on the project does.