[prev] [thread] [next] [lurker] [Date index for 2006/06/19]
* 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.
--
-D. dgc@xxxxxxxx.xxx NSIT University of Chicago
There's stuff above here
Generated at 20:01 on 27 Jun 2006 by mariachi 0.52