Date: Tue, 2 Apr 2002 15:55:02 -0500 (EST) From: Kenneth Culver <culverk@alpha.yumyumyum.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Mike Barcroft <mike@FreeBSD.ORG>, "M. Warner Losh" <imp@village.org>, <jake@locore.ca>, <cvs-committers@FreeBSD.ORG>, <cvs-all@FreeBSD.ORG> Subject: Re: cvs commit: src/sys/i386/i386 critical.c src/sys/i386/include cpufunc.h critical.h src/sys/i386/isa apic_vector.s icu_vector.s src/sys/kern kern_fork.c kern_proc.c kern_switch.c src/sys/alpha/alph Message-ID: <20020402154308.F46914-100000@alpha.yumyumyum.org> In-Reply-To: <200204021802.g32I2IY16755@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> :> > x;
> :> > y;
> :> > } else
> :> > /*
> :> > * HITHERE!
> :> > */
> :> > b;
> :>
> :> This looks better with proper 8 character tabs. I think in KNF extra
> :> braces are normally used in situations like this, but this is an edge
> :> case.
> :
> :8 character tabs? why use tabs at all? That requires an
> :engineer/programmer to set that in an editor, and a lot of people don't
> :like having tabs that are that large... I just use spaces because then my
> :code will look the same as when I wrote it no matter what editor is used,
> :and no matter what the tabs are set to.
>
> Ha. This argument goes back forever. In the early days people used all
> sorts of different indentation. 2, 3, 4, 8... everything under the sun.
> In those days disk space was at a premium, so many of these people
> changed the interpretation of a 'hard tab' to match their indentation.
>
> It caused no end of trouble. Source code would often not be portable
> between text editors or even be printable without some massaging. This
> is, amoung other things, what led to vi's first-line-of-file-contains-vi-
> options feature.
>
> These days virtually everyone I know who used to use weird tabbing
> conventions now uses hard tabs of 8, period, no matter what their
> favorite indentation is. So if you look at a piece of code that
> uses an indentation of 4 you will find that every other indentation
> level has a bunch of spaces to make up the difference.
>
> a
> b
> c
> d
>
> <4xSPACE> + a
> <TAB> + b
> <TAB> + <4xSPACE> + c
> <TAB> + <TAB> + d
>
> Even though disk space is no longer at a premium, it still offends
> people's sensibilities when they see a source file bloated to 2x or 3x
> its normal size when spaces are used to handle deep indentations. So
> tabs (fixed at 8) still have meaning.
>
Well, I havn't been around since those days, but disk space is cheap now,
so I'm not sure that whole file bloat b/c of spaces being used instead of
tabs is valid either, at least not anymore. All I'm saying is that if
everyone just uses spaces, then a certain piece of code will look the same
no matter what the tabstops are, and no matter what else. I know there are
many engineers that do NOT like to use tabstops of 8 simply because they
cause one to get to the end of an 80 character line too quickly:
(This is with 8 char tabs on my emailer)
if(blah) {
ret = foo();
while(something) {
if(ret && some->wierd->thing->that->takes->up->too
->much->space) {
more code here.... notice that I don't
have much room to type now and I'm hitting
enter and going to the next line at an
annoyingly large number of times
}
}
}
Basically, I think that code would be more readable with smaller tabs, so
say I want to use 4 space tabs, I wouldn't have to keep continuing on the
next line all the time. I know this is personal opinion, and personal
coding style, but if I use spaces, every engineer/programmer that looks at
my code will see the code the way I originally wrote it. I don't care if
it takes extra space because I have 30 GB of disk space (or 10, or 5,
either way it doesn't really matter that much anymore because disk space
is cheap).
Again, I know this is all personal opinion, but I think it's much more
simple. :-)
Ken
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020402154308.F46914-100000>