FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

Oh, my.  Who would have thought that in 2002 people would still be arguing
about the tenth ascii character?  Don't you people have girlfriends?  

Brian:        tabs @ 5
Nick:         tabs @ 2 or none
Fridiano:     tabs @ 5 or none
Bob:                      none
Bill:                     none
jkl:          pish-posh

>From this, we can conclude that people with short names like tabs less or at
shorter settings than people with long names do.  

I don't see what "the majority of terminals in their default configuration"
has to do with anything.  Good grief!  I should edit my code according to
what xterm(1) thinks is a reasonable tabstop?  Please.  

Tabs are a *feature*.  If we use tabs, for the most part we can set our
tabstops where we want to and let each see the code with his preferred
amount of lefthand whitespace.  

The problem arises when people lean on the spacebar instead of the tab key,
or use an editor that writes N spaces every time <tab> is pressed.  I've
always thought the latter was a braindead nonfeature, because it's
asymmetrical: press <tab> once and you have to press <backspace> N times to
undo it.  Strictly dopey.  Also, it inevitably leads to off-by-one
(indentation) errors, because people get it wrong from time to time.  

I know, there are times when you need to line things up, like when you do
something like:

     if (blah giant test
         || other possibility) {
        [your code here]
     }

which, btw is why God intended tabstops to be at 3. ;)  My assertion is, if
you do this and it doesn't line up according to the prescribed tabstop --
currently 5 -- then you did it wrong.  If you like (as I do) something other
than 5, correctly indented code will look a little wavy in those places.
That's not such a high price to pay for everyone else's flexibility.  

For the record, I use 3 for C, 4 for perl, and 8 for SQL.  I'm OK with 4 or
5, in the spirit of community.  

--jkl

> -----Original Message-----
> From: Castellano, Nicholas [mailto:Nicholas_Castellano AT acml.com]
> Sent: October 23, 2002 9:58 AM
> To: TDS Development Group
> Subject: [freetds] Re: indent(1) bent
> 
> 
> Anything that assumes a tab stop other than 8 spaces will 
> look like crap on
> the majority of terminals in their default configuration.
> 
> We should either use a tab stop of 8, or no tabs at all.
> 
> My personal preferences are no tabs, and an indentation of 
> two spaces per
> indent level (it's much easier than counting to 3 or 5 or 8 
> or whatever a
> billion times a day...)
> 
> Cheers,
> --nick
> 
> -----Original Message-----
> From: bounce-freetds-145195 AT franklin.oit.unc.edu
> [mailto:bounce-freetds-145195 AT franklin.oit.unc.edu] 
> Sent: Wednesday, October 23, 2002 9:47 AM
> To: TDS Development Group
> Subject: [freetds] Re: indent(1) bent
> 
> 
> > 
> > On Wed, 23 Oct 2002, James K. Lowden wrote:
> > 
> > > I like tabs.  They're more flexible than blanks.
> > 
> > I know this risks starting a religious bloodbath, but I'll 
> register a 
> > different opinion.  I think tabs are horrible.  Ever since 
> editors had 
> > the capability of visually representing tabs as a 
> configurable number 
> > of spaces (a long time ago) I've worked on few multi-developer
> > projects in
> > which all the developers agreed on (a) whether tabs should 
> be used and
> > (b) how many spaces the tabs represent.  As a result, most 
> source code
> > ends up very difficult to read, because no matter what you tell your
> > editor about how to represent the tab, code which has been 
> touched by
> > more than one developer doesn't have consistent visual indentation.
> > The only projects on which consistent, legible code had a 
> prayer were
> > those in which hard tabs were avoided completely.
> > 
> > That's my 2 cents.
> > 
> 
> In fact I propose two options. Or all use an indentation of 5 
> spaces or we
> indent with a tab that represent 5 space (so developer can 
> set tabspace to
> whatever he want changing indentation look). 
> It's supposed that after we indent all code all newe code 
> will be indented
> in such way before committing... so the problem will be 
> resolved... (I hope)


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.