From: Jeremy Stephens Date: 21:58 on 19 Jun 2006 Subject: tabs in source code I hate tabs in source code. If you must use them, expand them into spaces please if you think anyone will ever want to read it. Hatefully yours, Jeremy
From: David Champion
Date: 22:14 on 19 Jun 2006
Subject: Re: tabs in source code
* On 2006.06.19, in <44970FFF.4050701@xxxxxxxxxx.xxx>,
* "Jeremy Stephens" <jeremy.f.stephens@xxxxxxxxxx.xxx> wrote:
> I hate tabs in source code. If you must use them, expand them into
> spaces please if you think anyone will ever want to read it.
Yes, I hate when people use tabs instead of spaces -- but I also hate
when people use spaces instead of tabs.
They work fine together if you only tab where you want tabs and only
space where you want spaces. (Hint: spaces are character-sized, and
tabs are tab-sized.)
int
main(int argc, char *argv[])
{
printf("like this: %s\n",
"spaces");
exit(0);
}
That works wonderfully with any tab size.
From: A. Pagaltzis Date: 22:29 on 19 Jun 2006 Subject: Re: tabs in source code * David Champion <dgc@xxxxxxxx.xxx> [2006-06-19 23:15]: > Yes, I hate when people use tabs instead of spaces -- but I > also hate when people use spaces instead of tabs. > > They work fine together if you only tab where you want tabs and > only space where you want spaces. (Hint: spaces are > character-sized, and tabs are tab-sized.) * Jeremy Weathers <jer@xxxx.xxx> [2006-06-19 23:20]: > I hate multiple spaces in source code when a single tab does > the job of indenting the code just fine. […] Please convert > your spaces into tabs if you think anyone will ever want/need > to edit your code. I am elated to find myself in such enlightened company. I thought I was the only one. With deep regards,
From: Jeremy Stephens Date: 22:38 on 19 Jun 2006 Subject: Re: tabs in source code David Champion wrote: > Yes, I hate when people use tabs instead of spaces -- but I also hate > when people use spaces instead of tabs. > > They work fine together if you only tab where you want tabs and only > space where you want spaces. (Hint: spaces are character-sized, and > tabs are tab-sized.) > You make a good point. I just hate it when the behavior switches halfway through the code. I'm OK with only tabs if that's all someone uses, and your methodology would also be fine. But don't use 4 spaces at one level of indentation and a tab at the next level, assuming that everyone keeps their default tab width at 8 (which is what I'm dealing with at the moment).
From: Luke Kanies Date: 22:42 on 19 Jun 2006 Subject: Re: tabs in source code On Jun 19, 2006, at 2:38 PM, Jeremy Stephens wrote: >> > You make a good point. I just hate it when the behavior switches > halfway through the code. I'm OK with only tabs if that's all someone > uses, and your methodology would also be fine. But don't use 4 spaces > at one level of indentation and a tab at the next level, assuming that > everyone keeps their default tab width at 8 (which is what I'm dealing > with at the moment). I'd have to say that my main hate in this space is stupid Emacs, which (by default, from what I can tell) uses 4 spaces for the first tab and a full tab for the second tab. It's absolutely evil.
From: Martin Ebourne Date: 23:09 on 19 Jun 2006 Subject: Re: tabs in source code On Mon, 2006-06-19 at 14:42 -0700, Luke Kanies wrote: > I'd have to say that my main hate in this space is stupid Emacs, > which (by default, from what I can tell) uses 4 spaces for the first > tab and a full tab for the second tab. It's absolutely evil. I've no idea where that's come from because Emacs (at least GNU Emacs) certainly doesn't do that by default. By default it uses tab stops at 8 characters, the same as every other unix tool. Of course it's easy to change to any value you like, or you can be more specific and set it individually for certain modes, buffers, or indentation styles. Cheers, Martin.
From: David Champion Date: 23:16 on 19 Jun 2006 Subject: Re: tabs in source code * On 2006.06.19, in <1150754996.14892.12.camel@xxxxxx.xxxxxxx.xx.xx>, * "Martin Ebourne" <lists@xxxxxxx.xx.xx> wrote: > > I've no idea where that's come from because Emacs (at least GNU Emacs) > certainly doesn't do that by default. By default it uses tab stops at 8 > characters, the same as every other unix tool. Perhaps "default" wasn't the best word choice to an emacs user, but it feels right if you've shared the same hate. It's probably from cc-mode. Try it. emacs bloody-emacs.c and put in some levels of indentation, then check it out in vi or od. It does appear that somewhere in the last 12 years they've changed it from 4 spaces (also my recollection) to 2 spaces; hate.
From: Martin Ebourne
Date: 00:38 on 20 Jun 2006
Subject: Re: tabs in source code
On Mon, 2006-06-19 at 17:16 -0500, David Champion wrote:
> It's probably from cc-mode. Try it. emacs bloody-emacs.c and put in
> some levels of indentation, then check it out in vi or od.
>
> It does appear that somewhere in the last 12 years they've changed it
> from 4 spaces (also my recollection) to 2 spaces; hate.
% emacs -Q bloody-emacs.c
Entered the code below which indented to look exactly like this[1]:
int main()
{
if(friday()) {
while(procrastinating()) {
switch(toaster_on(sliced_bread)) {
case Golden:
add_cheese();
have_tea();
break;
case Black:
sulk();
}
}
}
return 0;
}
% cat -vet bloody-emacs.c
int main()$
{$
if(friday()) {$
while(procrastinating()) {$
switch(toaster_on(sliced_bread)) {$
case Golden:$
^Iadd_cheese();$
^Ihave_tea();$
^Ibreak;$
$
case Black:$
^Isulk();$
}$
}$
}$
$
return 0;$
}$
That looks perfectly understandable and sane. It's indented 2 spaces
each time and used a tab instead of 8 spaces. This corresponds with the
defaults of every other unix tool so at least it will display correctly
and look correct by default in any normal editor.
But of course, it's still mixed tabs with spaces in an evil manner
(virtually every tab/space mix is evil, apart from the anal retentive
one, which is just well, you get it). Fortunately one setting later and
it won't do that any more. [2]
Cheers,
Martin.
[1] Note that to display it to yourselves accurately as it appears on my
screen I had to convert the tabs to spaces. That's a hint people.
[2] Emacs has a mode which lets you edit C code in the "correct"
tab/space mix and it handles getting it right automatically. If everyone
used this I'd be happy to as well, but no-one does, so there's no point
me caring.
From: peter (Peter da Silva) Date: 22:55 on 23 Jun 2006 Subject: Re: tabs in source code > I'd have to say that my main hate in this space is stupid Emacs, > which (by default, from what I can tell) uses 4 spaces for the first > tab and a full tab for the second tab. It's absolutely evil. You broke my brane. Stop that.
From: David Cantrell Date: 16:20 on 20 Jun 2006 Subject: Re: tabs in source code On Mon, Jun 19, 2006 at 04:38:32PM -0500, Jeremy Stephens wrote: > You make a good point. I just hate it when the behavior switches > halfway through the code. Guilty as charged. That's because I use sane whitespace but the previous author used shitespace.
From: Smylers
Date: 23:18 on 19 Jun 2006
Subject: Re: tabs in source code
David Champion writes:
> I also hate when people use spaces instead of tabs. ... They work
> fine together if you only tab where you want tabs ...
>
> int
> main(int argc, char *argv[])
> {
> printf("like this: %s\n",
> "spaces");
> exit(0);
> }
>
> That works wonderfully with any tab size.
No it doesn't.
For a start, now that I've quoted your code (with a less-than sign and a
space) only the code that was hard left against the edge has moved; the
other lines now have a tab which is giving an effective indent of 2
characters less than before, (and less than other indentation levels, if
there were any). You get a similar effect when diff-ing code puts
symbols in the first column to indicate removals and additions.
Also, I'm not that bothered how big indentation levels are, but I do
care that source code lines don't exceed 80 characters: I want them to
fit in a standard size terminal, to be readable in an e-mail message, to
be able to run diff on code and not find the lines are so long that it
takes a dedicated 'Where's Wally'[*0] watcher to spot where the actual
differences are.
And if tabs are variable, you can't know the length of a line, therefore
you can't break them before 80 characters.
Smylers
[*0] 'Where's Waldo', I believe, in some jurisdictions.
From: David Champion
Date: 23:56 on 19 Jun 2006
Subject: Re: tabs in source code
* On 2006.06.19, in <20060619221805.GA7930@xxxxxxx.xxx>,
* "Smylers" <Smylers@xxxxxxx.xxx> wrote:
> >
> > int
> > main(int argc, char *argv[])
> > {
> > printf("like this: %s\n",
> > "spaces");
> > exit(0);
> > }
>
> For a start, now that I've quoted your code (with a less-than sign and a
> space) only the code that was hard left against the edge has moved; the
> other lines now have a tab which is giving an effective indent of 2
> characters less than before, (and less than other indentation levels, if
> there were any). You get a similar effect when diff-ing code puts
> symbols in the first column to indicate removals and additions.
This has never bothered me. I can read code at indentation levels
besides my natural one, and anyway I rarely quote my code.
But more importantly, it can be corrected (if it's incorrect in your
judgement). Why? Because there's semantic value in a tab which you can
translate for viewing into 8 spaces, or 5 spaces, or a picture of a dead
armadillo if it makes you happy. There's no semantic value in a bunch
of spaces. I can't turn a bunch of spaces into something that makes me
happy.
> And if tabs are variable, you can't know the length of a line, therefore
> you can't break them before 80 characters.
No matter what my actual preferred tab size is locally, I generally
edit my line lengths at ts=8, just to make them fit with any common tab
size. If I turned my tabs into 8 spaces to make them comply with your
preferences, it's be no better and no worse with respect to line length,
but I'd have lost semantic value.
You just have to be careful and perhaps a little anal-retentive. It's
not the use of tabs that rots things up, it's how they're used.
From: A. Pagaltzis Date: 23:57 on 19 Jun 2006 Subject: Re: tabs in source code * Smylers <Smylers@xxxxxxx.xxx> [2006-06-20 00:20]: > Also, I'm not that bothered how big indentation levels are, but > I do care that source code lines don't exceed 80 characters: I > want them to fit in a standard size terminal, to be readable in > an e-mail message, to be able to run diff on code and not find > the lines are so long that it takes a dedicated 'Where's > Wally'[*0] watcher to spot where the actual differences are. I never understood this. I tried to follow the rule for a long time, but I found that when a line is 200 characters long, you either did something wrong and should break it up into a few separate steps, at which point the matter solves itself. Or it really has to be 200 characters long, in which case all attempts to fit it into 80 column lines are contortions that serve no other purpose than to distract while reading but particularly while writing. Any code formatting rule that cannot be formalised so that software can do it is a bad formatting rule; and an aesthetically pleasing choice of arbitrary places to break code in order to fit it into a straightjacket is impossible to formalise. So my code is generally well within 80 columns for any sane (or even just vaguely sane) tab width, and I happily accept the few overlong lines that do come up. Regards,
From: Sean Conner Date: 01:13 on 20 Jun 2006 Subject: Re: tabs in source code It was thus said that the Great A. Pagaltzis once stated: > * Smylers <Smylers@xxxxxxx.xxx> [2006-06-20 00:20]: > > Also, I'm not that bothered how big indentation levels are, but > > I do care that source code lines don't exceed 80 characters: I > > want them to fit in a standard size terminal, to be readable in > > an e-mail message, to be able to run diff on code and not find > > the lines are so long that it takes a dedicated 'Where's > > Wally'[*0] watcher to spot where the actual differences are. > > I never understood this. > > I tried to follow the rule for a long time, but I found that when > a line is 200 characters long, you either did something wrong and > should break it up into a few separate steps, at which point the > matter solves itself. Or it really has to be 200 characters long, > in which case all attempts to fit it into 80 column lines are > contortions that serve no other purpose than to distract while > reading but particularly while writing. XSLT anyone? [1] There are quite a few lines I wrote in XSLT that exceed 200 characters (even if flush left, they would *still* be in excess of 200 characters). -spc (But once having written the XSLT files, it's now trivial to add pages and whole new subsections to my site ... ) [1] Self-inflicted hate. I thought it would be nice to store my website [2] as XML and use XSLT to convert it to HTML pages (mostly to autogenerate the nagivation links). A purely functional programming language that is *more* annoying than Perl, Lisp *and* Forth put together. [2] For those that might be interested: http://www.conman.org/
From: Foofy Date: 08:12 on 20 Jun 2006 Subject: Re: tabs in source code On Mon, 19 Jun 2006 20:13:11 -0400, Sean Conner <spc@xxxxxx.xxx> wrote: > XSLT anyone? [1] There are quite a few lines I wrote in XSLT that > exceed > 200 characters (even if flush left, they would *still* be in excess of > 200 > characters). I just put each attribute on its own line. Easier to read and edit. <element attr='blahblah' attr='blahblah' attr='blahblah' />
From: David Cantrell Date: 16:56 on 20 Jun 2006 Subject: Re: tabs in source code On Tue, Jun 20, 2006 at 03:12:46AM -0400, Foofy wrote: > I just put each attribute on its own line. Easier to read and edit. > <element > attr='blahblah' > attr='blahblah' > attr='blahblah' > /> Ahhhh, the language that has twice the brackets of Lisp with half the functionality. Lovely.
From: Foofy Date: 18:56 on 20 Jun 2006 Subject: Re: tabs in source code On Tue, 20 Jun 2006 11:56:13 -0400, David Cantrell <david@xxxxxxxx.xxx.xx> wrote: > Ahhhh, the language that has twice the brackets of Lisp with half the > functionality. Lovely. It's kind of sad because XSLT does have its uses and is more straightforward in _some_ cases. Too bad it's a whore to type. That said, XML/HTML got easier to type when I switched to Dvorak as the brackets are where Q and W used to be. Small change but it makes a huge difference! I'm still suprised no text editor is smart enough to recognize element names as you type them and add the brackets automatically.
From: Jarkko Hietaniemi Date: 17:04 on 26 Jun 2006 Subject: Re: tabs in source code David Cantrell wrote: > On Tue, Jun 20, 2006 at 03:12:46AM -0400, Foofy wrote: > >> I just put each attribute on its own line. Easier to read and edit. >> <element >> attr='blahblah' >> attr='blahblah' >> attr='blahblah' >> /> > > Ahhhh, the language that has twice the brackets of Lisp with half the > functionality. Lovely. Half? HALF?!
From: Daniel Pittman Date: 01:19 on 27 Jun 2006 Subject: Re: tabs in source code Jarkko Hietaniemi <jhi@xxx.xx> writes: > David Cantrell wrote: >> On Tue, Jun 20, 2006 at 03:12:46AM -0400, Foofy wrote: >> >>> I just put each attribute on its own line. Easier to read and edit. >>> <element >>> attr='blahblah' >>> attr='blahblah' >>> attr='blahblah' >>> /> >> >> Ahhhh, the language that has twice the brackets of Lisp with half the >> functionality. Lovely. > > Half? HALF?! Yeah, about half normally, and with none of the sensible, well defined semantics or useful constancy to the structure. Because having random distinctions between data formats, and a "not quite structured" set of text settings is so much saner than the Lisp model of "everything works this one, single, simple way." At least XSLT isn't as bad as the wretched specification that actually *did* implement Lisp in XML, by grafting in a syntax for evaluating XML expressions. Thankfully that died the miserable and stupid death it deserved, eh? Daniel
From: Jarkko Hietaniemi Date: 05:06 on 27 Jun 2006 Subject: Re: tabs in source code >>> Ahhhh, the language that has twice the brackets of Lisp with half the >>> functionality. Lovely. >> Half? HALF?! > > Yeah, about half normally, and with none of the sensible, well defined > semantics or useful constancy to the structure. > > Because having random distinctions between data formats, and a "not > quite structured" set of text settings is so much saner than the Lisp > model of "everything works this one, single, simple way." > > > At least XSLT isn't as bad as the wretched specification that actually > *did* implement Lisp in XML, by grafting in a syntax for evaluating XML > expressions. > > Thankfully that died the miserable and stupid death it deserved, eh? Sir, you need to practice more the noble art of trolling. > Daniel
From: peter (Peter da Silva) Date: 23:04 on 23 Jun 2006 Subject: Re: tabs in source code > in which case all attempts to fit it into 80 column lines are > contortions that serve no other purpose than to distract while > reading but particularly while writing. You're confusing lines and statements. A statement can contain multiple lines. Whether a statement should go on multiple lines or not is only loosely related to length. a = function(a fairly complex expression, another expression); That fits on one line, but I'm inclined to write it as: a = function( a fairly complex expression, another expression ); Simply because it's easier to read and provides redundancy and documentation. Possibly my Lisp is showing. > Any code formatting rule that cannot be formalised so that > software can do it is a bad formatting rule; That's fine, documentation isn't "a formatting rule". You might as well say the same thing about comment and function name rules.
From: A. Pagaltzis
Date: 05:09 on 24 Jun 2006
Subject: Re: tabs in source code
* Peter da Silva <peter@xxxxxxx.xxx> [2006-06-24 00:10]:
> > in which case all attempts to fit it into 80 column lines are
> > contortions that serve no other purpose than to distract
> > while reading but particularly while writing.
>
> You're confusing lines and statements.
Not at all.
> a = function(a fairly complex expression, another expression);
>
> That fits on one line, but I'm inclined to write it as:
>
> a = function(
> a fairly complex expression,
> another expression
> );
Yes, so do I. Btw, kudos for *not* writing it as
a = function(a fairly complex expression,
another expression);
as many C people do. Ugh.
> Simply because it's easier to read and provides redundancy and
> documentation.
I was with you up to "easier to read", but uh, where's the
redundancy and documentation in that example?
> > Any code formatting rule that cannot be formalised so that
> > software can do it is a bad formatting rule;
>
> That's fine, documentation isn't "a formatting rule". You might
> as well say the same thing about comment and function name
> rules.
Not at all the same thing. Code layout and identifier names play
in completely different leagues.
Regards,
From: peter (Peter da Silva)
Date: 14:47 on 24 Jun 2006
Subject: Re: tabs in source code
pagaltzis@xxx.xx (A. Pagaltzis):
> I was with you up to "easier to read", but uh, where's the
> redundancy and documentation in that example?
It's easier to read because it contains redundant information that documents
the intent of the author better than a raw stream of tokens. That's the whole
point of indenting code at all (in sane languages, anyway).
Another example of layout as redundant documentation that might be easier:
puts("<BLOCKQUOTE>");
put_escaped(quoted_text);
puts("<DIV ALIGN=RIGHT>");
puts("--");
put_escaped(attribution);
puts("</DIV>");
puts("</BLOCKQUOTE>");
Or, layout coming to the aid of comments:
/* name type variable bound_var */
add_symbol("height", REAL, TRUE, &height);
add_symbol("weight", REAL, TRUE, &weight);
add_symbol("buttons", INTEGER, TRUE, &buttons);
In some languages you can bring named arguments to play, but it's still
worthwhile:
add-symbol "height" -type REAL -variable -bind height
add-symbol "weight" -type REAL -variable -bind weight
add-symbol "buttons" -type INTEGER -variable -bind buttons
> Not at all the same thing. Code layout and identifier names play
> in completely different leagues.
But they play the same sport. We're comparing College with Pro, not Rugby
with Cricket.
From: peter (Peter da Silva) Date: 22:57 on 23 Jun 2006 Subject: Re: tabs in source code > And if tabs are variable, you can't know the length of a line, therefore > you can't break them before 80 characters. Tabs Aren't Variable.
From: Martin Ebourne Date: 23:01 on 23 Jun 2006 Subject: Re: tabs in source code On Fri, 2006-06-23 at 16:57 -0500, Peter da Silva wrote: > > > And if tabs are variable, you can't know the length of a line, therefore > > you can't break them before 80 characters. > > Tabs Aren't Variable. As much as I wish you were right there, and as much as I agree with you in theory, there's too many years of experience beaten painfully into my bones for that to be truly convincing. Cheers, Martin.
From: peter (Peter da Silva) Date: 14:08 on 24 Jun 2006 Subject: Re: tabs in source code Martin Ebourne: > As much as I wish you were right there, and as much as I agree with you > in theory, there's too many years of experience beaten painfully into my > bones for that to be truly convincing. Tabs Aren't Variable. When you come across code written by anyone who thinks otherwise, beat 'em back.
From: Jeremy Weathers
Date: 22:14 on 19 Jun 2006
Subject: Re: tabs in source code
> I hate tabs in source code. If you must use them, expand them
> into spaces please if you think anyone will ever want to read
> it.
I hate multiple spaces in source code when a single tab does the job
of indenting the code just fine. If you prefer a level of
indentation for tabs other than your editor's default (and I
understand your preference if you're using any of the linux utils
that think 8 spaces is the perfect indention), please take one
minute to change your editor's default to your preference (that's
why it is a user-editable setting).
Please convert your spaces into tabs if you think anyone will ever
want/need to edit your code.
--=20
Jeremy Weathers
Sony-Ericsson: We put the "slow" in
"Damn, this crappy phone is slow!"
- Wil Shipley
From: Martin Ebourne Date: 22:31 on 19 Jun 2006 Subject: Re: tabs in source code On Mon, 2006-06-19 at 16:14 -0500, Jeremy Weathers wrote: > I hate multiple spaces in source code when a single tab does the job > of indenting the code just fine. Tabs/spaces whatever. There's not a single tool that will misformat code only using spaces, whereas the majority of tools will need to be set up to show tabs correctly, and that's assuming the indentation levels across all of the code bases you use are consistent. Sure that doesn't matter if tabs are used for nested indentation and spaces for formatting, but unless you wrote the code yourself (or the code's author was anal retentive) the chances of that are approximately 0%. Spaces it is, for portability sakes. Unless you're not being portable of course in which case be happy, you've got life easy. > Please convert your spaces into tabs if you think anyone will ever > want/need to edit your code. Or just get an editor that deals with whatever crap you throw at it in a consistent manner without giving you shit. If yours doesn't, then hate your editor (and get a better one!). Cheers, Martin.
From: A. Pagaltzis Date: 22:51 on 19 Jun 2006 Subject: Re: tabs in source code * Martin Ebourne <lists@xxxxxxx.xx.xx> [2006-06-19 23:35]: > Sure that doesn't matter if tabs are used for nested > indentation and spaces for formatting, but unless you wrote the > code yourself (or the code's author was anal retentive) the > chances of that are approximately 0%. I am anal retentive and proud of it. And I expect no less of anyone else. Regards,
From: peter (Peter da Silva) Date: 22:54 on 23 Jun 2006 Subject: Re: tabs in source code > Tabs/spaces whatever. There's not a single tool that will misformat code > only using spaces, whereas the majority of tools will need to be set up > to show tabs correctly, The majority of tools are misconfigured? Oh, right, they're software, and therefore hateful. > Spaces it is, for portability sakes. Unless you're not being portable of > course in which case be happy, you've got life easy. If your code is made non-portable if spaces and tabs don't behave the way you expect, then the language itself is hateful. Yes, Python, Make, I'm talking about you.
From: Martin Ebourne Date: 22:59 on 23 Jun 2006 Subject: Re: tabs in source code On Fri, 2006-06-23 at 16:54 -0500, Peter da Silva wrote: > > > Tabs/spaces whatever. There's not a single tool that will misformat code > > only using spaces, whereas the majority of tools will need to be set up > > to show tabs correctly, Back to the email hate. People who loose attributions completely. I reckon however some of these might be my words. > The majority of tools are misconfigured? > > Oh, right, they're software, and therefore hateful. Naturally. > > Spaces it is, for portability sakes. Unless you're not being portable of > > course in which case be happy, you've got life easy. > > If your code is made non-portable if spaces and tabs don't behave the > way you expect, then the language itself is hateful. Yes, Python, Make, > I'm talking about you. I didn't mean portable in the sense of whether it executes or not. I meant portable in the case of being able to usefully maintain it on a variety of different platforms/setups. And to the hateful indentation list you could add a few more, OCCAM springs to mind. Cheers, Martin.
From: Bruce Richardson Date: 23:27 on 23 Jun 2006 Subject: Re: tabs in source code On Fri, Jun 23, 2006 at 10:59:23PM +0100, Martin Ebourne wrote: > Back to the email hate. People who loose attributions completely. I People who can't spell lose.
From: Chris Cantrall Date: 00:26 on 24 Jun 2006 Subject: Re: tabs in source code On 6/23/06, Martin Ebourne <lists@xxxxxxx.xx.xx> wrote: >I meant portable in the case of being able to usefully >maintain it on a variety of different platforms/setups. Yes, that's an absolute requirement. Because the simple things should be common across all systems. Simple things, like newlines. It'd be simply stupid for one system to have a newline that was different from another system. Oh, wait. Uh, nevermind.
From: peter (Peter da Silva) Date: 14:04 on 24 Jun 2006 Subject: Re: tabs in source code I used to remove the quoted text as well. Makes the thread look better at http://viking.hates-software.com/2006/06/19/5d56f668.html .
From: Martin Ebourne Date: 14:08 on 24 Jun 2006 Subject: Re: tabs in source code On Sat, 2006-06-24 at 08:04 -0500, Peter da Silva wrote: > I used to remove the quoted text as well. Makes the thread look better > at http://viking.hates-software.com/2006/06/19/5d56f668.html . The blog software could and should do that for itself. Software that makes users contort to it is hateful. Cheers, Martin.
From: David Cantrell Date: 12:29 on 27 Jun 2006 Subject: Re: tabs in source code On Fri, Jun 23, 2006 at 04:54:23PM -0500, Peter da Silva wrote: > If your code is made non-portable if spaces and tabs don't behave the > way you expect, then the language itself is hateful. Yes, Python, Make, > I'm talking about you. <self-hate> rsnapshot's config files too </self-hate>
From: jrodman Date: 03:30 on 20 Jun 2006 Subject: Re: tabs in source code On Mon, Jun 19, 2006 at 04:14:55PM -0500, Jeremy Weathers wrote: > > I hate tabs in source code. If you must use them, expand them > > into spaces please if you think anyone will ever want to read > > it. > > I hate multiple spaces in source code when a single tab does the job > of indenting the code just fine. Oh the humanity! There are better forms of compression, people.
From: A. Pagaltzis Date: 04:19 on 20 Jun 2006 Subject: Re: tabs in source code * jrodman@xxxx.xxxxxxxxxx.xxx <jrodman@xxxx.xxxxxxxxxx.xxx> [2006-06-20 04:35]: > On Mon, Jun 19, 2006 at 04:14:55PM -0500, Jeremy Weathers wrote: > > I hate multiple spaces in source code when a single tab does > > the job of indenting the code just fine. > > Oh the humanity! > > There are better forms of compression, people. Who said anything about compression? Entities should not be multiplied unnecessarily, that’s all. Regards,
From: Robert G. Werner Date: 00:51 on 20 Jun 2006 Subject: Re: tabs in source code Jeremy Stephens wrote: > I hate tabs in source code. If you must use them, expand them into > spaces please if you think anyone will ever want to read it. > > Hatefully yours, > Jeremy > I just love flame wars about spaces vs. tabs. ;-) Anyone for VIM vs. Emacs next? When can I schedule American Football vs. (Rest of World) Football?
From: Mike Macgirvin Date: 01:46 on 20 Jun 2006 Subject: Re: tabs in source code > I just love flame wars about spaces vs. tabs. ;-) > > Anyone for VIM vs. Emacs next? When can I schedule American Football > vs. (Rest of World) Football? First we have to go through the 'One True Bracing Style' debate. I've been through this so many times that the progression is predictable. - email inclusion formats and sig files - tabs vs. spaces - bracing style - editor preferences - gun control - Hitler When somebody finally brings up how Hitler would've done this or that, the thread has finally been beaten to death. At one of my employers, when we got to tabs and spaces we would just declare 'hitler' on the thread and save filling everybody's mailbox with three thousand messages covering all the intervening subjects. Hitler. Folks the only person who cares how you write code is the guy/gal who has to fix your bugs - and perhaps your boss, because he/she will have to hire the person to fix your bugs.
From: Phil!Gregory Date: 03:44 on 20 Jun 2006 Subject: Re: tabs in source code * Mike Macgirvin <mike@xxxxxxxxx.xxx> [2006-06-19 17:46 -0700]: > - email inclusion formats and sig files Don't forget its close cousin, mailing list software and the Reply-To: header. (The tabs vs. spaces thread _could_ be hijacked into a make hate, but that's ossified hate by now.)
From: Juerd Date: 01:51 on 20 Jun 2006 Subject: Re: tabs in source code Robert G. Werner skribis 2006-06-19 16:51 (-0700): > Anyone for VIM vs. Emacs next? There's no need. Everyone on this list already knows that VIM is infinitely better. :) Juerd
From: Guy Thornley Date: 02:32 on 20 Jun 2006 Subject: Re: tabs in source code > > Anyone for VIM vs. Emacs next? We could do mail clients? How about this -- mail client handling of tabs! Two birds with one stone! It will even keep the thread (mostly) on-topic, too. Bonus! I have actually needed to installed my own 'sendmail' script which passes the input through 'pr' first to expand the tabs. Why? Because some mail clients, yes, Outlook, are *incapable* of displaying tabs correctly. I bumped into this with my old boss here, when I was sending nicely tab-formatted emails, and they were being completely munged by whatever edition/perversion of outlook he was running. It was treating the tabs HTML style - you know, as a single character of whitespace. I'm *fairly* sure the default mail style was set to plain text, because I guided him on this, and we checked! Incidentally, the default setting of a proportional font for plain text mail is utterly hateful. Outlook hate deserves a whole hate-thread of its own, I'm sure :) Even from us types that don't use it, but occasionally attempt to communicate with those that do.. - Guy
From: Robert G. Werner Date: 04:16 on 20 Jun 2006 Subject: Outlook (was: Re: tabs in source code) Guy Thornley wrote: [snip] > Outlook hate deserves a whole hate-thread of its own, I'm sure :) Even from > us types that don't use it, but occasionally attempt to communicate with > those that do.. > > - Guy Don't get me started on Outlook. Who has ever heard of having two place in one file to store your fucking address book (and they really are two separate address books but they are live in one pile of shit called a PST). Also, outlook routinely munches up people's accounts who are using IMAP. It is hateful to have a fucking outbox where shit gets marooned for unknown reasons (usually because the address is wrong but not always). I hates. With white hot passion. Yet, I install Office on every new workstation we get. Sometimes, I hates being the Windows Admin.
From: Jarkko Hietaniemi Date: 17:02 on 26 Jun 2006 Subject: Re: Outlook Robert G. Werner wrote: > Guy Thornley wrote: > [snip] > >> Outlook hate deserves a whole hate-thread of its own, I'm sure :) Even from >> us types that don't use it, but occasionally attempt to communicate with >> those that do.. >> >> - Guy > Don't get me started on Outlook. > > Who has ever heard of having two place in one file to store your > fucking address book (and they really are two separate address books > but they are live in one pile of shit called a PST). Pile of ShiT - now it all finally makes sense!
From: A. Pagaltzis Date: 17:18 on 26 Jun 2006 Subject: Re: Outlook * Jarkko Hietaniemi <jhi@xxx.xx> [2006-06-26 18:05]: > Robert G. Werner wrote: > > Don't get me started on Outlook. > > > > Who has ever heard of having two place in one file to store > > your fucking address book (and they really are two separate > > address books but they are live in one pile of shit called a > > PST). > > Pile of ShiT - now it all finally makes sense! Maybe "Pile of Steamy Turds"? Regards,
From: Robert G. Werner Date: 21:27 on 26 Jun 2006 Subject: Re: Outlook A. Pagaltzis wrote: > * Jarkko Hietaniemi <jhi@xxx.xx> [2006-06-26 18:05]: [snip] >>> address books but they are live in one pile of shit called a >>> PST). >> Pile of ShiT - now it all finally makes sense! > > Maybe "Pile of Steamy Turds"? > > Regards, Oh how that does my soul good. Thank you for that!!!!
From: David Cantrell Date: 16:42 on 20 Jun 2006 Subject: Re: tabs in source code On Tue, Jun 20, 2006 at 02:51:46AM +0200, Juerd wrote: > Robert G. Werner skribis 2006-06-19 16:51 (-0700): > > Anyone for VIM vs. Emacs next? > There's no need. Everyone on this list already knows that VIM is > infinitely better. And for once, I have to agree. Everyone on *this* list does know that. The reason being that vim has less software, and so sucks less. It does still suck infinitely, of course.
From: Martin Ebourne Date: 17:47 on 20 Jun 2006 Subject: Re: tabs in source code David Cantrell <david@xxxxxxxx.xxx.xx> wrote: > On Tue, Jun 20, 2006 at 02:51:46AM +0200, Juerd wrote: >> Robert G. Werner skribis 2006-06-19 16:51 (-0700): >> > Anyone for VIM vs. Emacs next? >> There's no need. Everyone on this list already knows that VIM is >> infinitely better. > > And for once, I have to agree. Everyone on *this* list does know that. > The reason being that vim has less software, and so sucks less. It does > still suck infinitely, of course. And of course everyone on this list also knows that vi is better than vim. The reason being that vi has less software, and so sucks less. vi definitely sucks infinitely though. Cheers, Martin.
From: A. Pagaltzis Date: 19:20 on 20 Jun 2006 Subject: Re: tabs in source code * Martin Ebourne <lists@xxxxxxx.xx.xx> [2006-06-20 18:50]: > David Cantrell <david@xxxxxxxx.xxx.xx> wrote: > >And for once, I have to agree. Everyone on *this* list does > >know that. The reason being that vim has less software, and so > >sucks less. It does still suck infinitely, of course. > > And of course everyone on this list also knows that vi is > better than vim. The reason being that vi has less software, > and so sucks less. vi definitely sucks infinitely though. When I use an editor, I don't want eight extra KILOBYTES of worthless help screens and cursor positioning code! I just want an EDitor!! Not a "viitor". Not a "emacsitor". Those aren't even WORDS!!!! ED! ED! ED IS THE STANDARD!!! Regards,
From: Juerd Date: 22:33 on 20 Jun 2006 Subject: Re: tabs in source code A. Pagaltzis skribis 2006-06-20 20:20 (+0200): > When I use an editor, I don't want eight extra KILOBYTES of > worthless help screens and cursor positioning code! I just want > an EDitor!! Not a "viitor". Not a "emacsitor". Those aren't even > WORDS!!!! ED! ED! ED IS THE STANDARD!!! ?ED IS THE STANDARD? /Aristotle/ +kb ?From ?ka 'a,'bd w q vim
From: velut luna. immanis. Date: 01:26 on 21 Jun 2006 Subject: Re: tabs in source code There's only one solution that's viable and list-topical. Don't use spaces. Or tabs. Use stabs. STAB THE CODE! STAB IT GOOD!
From: Juerd Date: 02:14 on 21 Jun 2006 Subject: Re: tabs in source code velut luna. immanis. skribis 2006-06-20 17:26 (-0700): > There's only one solution that's viable and list-topical. > Don't use spaces. Or tabs. Speaking of topicality -- you replied to an editor holy war subthread, not any of the many whitespace style postings. Juerd
From: sabrina downard Date: 05:05 on 20 Jun 2006 Subject: Re: tabs in source code > I just love flame wars about spaces vs. tabs. ;-) > > Anyone for VIM vs. Emacs next? When can I schedule American Football > vs. (Rest of World) Football? i'm just grateful that someone else started the thread that dissolved into ranting, this time! and to put this on topic, ... firefox can still bite my shiny metal ass. --s. p.s. poor dgc and his tab-fetish has to work with me and my ":map! ^V^V^I ^V^V[space][space][space][space]' fetish. OH THE HUMANITY!
From: demerphq Date: 08:03 on 20 Jun 2006 Subject: Re: tabs in source code On 6/20/06, Robert G. Werner <robert@xxxxxxxxxxx.xxx> wrote: > Jeremy Stephens wrote: > > I hate tabs in source code. If you must use them, expand them into > > spaces please if you think anyone will ever want to read it. > > > > Hatefully yours, > > Jeremy > > > I just love flame wars about spaces vs. tabs. ;-) > > Anyone for VIM vs. Emacs next? When can I schedule American Football > vs. (Rest of World) Football? Since the World Cup is on right now I wouldn't recommend that one... Yves
From: Foofy Date: 08:39 on 20 Jun 2006 Subject: Re: tabs in source code On Mon, 19 Jun 2006 16:58:39 -0400, Jeremy Stephens <jeremy.f.stephens@xxxxxxxxxx.xxx> wrote: > I hate tabs in source code. If you must use them, expand them into > spaces please if you think anyone will ever want to read it. I hate spaces as tabs. There's a reason they're called spaces and not "one-eigth a tab." That said, I don't hate them as much as I hate people who can't respect the conventions used by the primary author or developer. It really pisses me off when some tweaker has converted all my tabs to spaces and then saved the file with a different encoding. Bastards. Not forcing your preferences on others is a good rule in general.
From: A. Pagaltzis Date: 12:52 on 20 Jun 2006 Subject: Re: tabs in source code * Foofy <foofy-lists@xxxxxx.xxx> [2006-06-20 09:45]: > Not forcing your preferences on others is a good rule in > general. Agreed, but that’s precisely a reason why I hate the abuse of spaces for indentation even more; being considerate in this way forces me to work with conventions that annoy the hell out of me. Hint: if you want others to write patches for you and you're using one of these insane mixed-tabs-and-spaces conventions, at least do them the favour of providing a modeline so they don't have to deduce your style from the code, then crack open the manual to research settings they never touch, and then fiddle these settings every time they want to go to work on your stuff. Even if it's a modeline for a different editor than the patcher uses, it's still useful. Regards,
From: peter (Peter da Silva) Date: 21:34 on 23 Jun 2006 Subject: Re: tabs in source code > I hate tabs in source code. If you must use them, expand them into > spaces please if you think anyone will ever want to read it. I hate non-standard tabstops in text editors. A tab every inch or 8 columns, thanks. If you can't read that, blame your editor.
Generated at 17:46 on 21 Sep 2006 by mariachi