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>