FreeTDS Development Group

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

> From: Bernd Jendrissek [mailto:berndj AT prism.co.za]
> Sent: October 23, 2002 5:19 PM

Bernd, 

I liked what you had to say.  Just a couple of comments.  

> Not that I actually hack freetds, but I've just spent a day 
> wading through
> code that's been through 2 or three different hands.  

/* cat foo.c with 8-wide tabs */
> int main()
> {
>       printf("Indentation as God intended it\n");
>       if (ts == 4) {
>     printf("Someone edited this with indentation 2\n");
>       }
> }

That's what the whole indentation discussion was provoked by.  Pretty soon,
you won't have to deal with that.  

> > >      if (blah giant test || other possibility) { 
                [your  code here] }
>          ^^^^
>        that's 4
> > 
> > > which, btw is why God intended tabstops to be at 3. ;)  
> 
> Why on earth would it be 3?

Oh, because I like my code to look like this:

        if (0 == 1)
           pi = 3;
        else {
           for (j=0; j < 10; j++) {
              yay4jay();
              alpha = omega;
           }
        }

I don't think the above would be improved by setting tabs to 8, and I don't
think they would be harmed by setting them to 4, or even harmed much by
setting them to 5. :)

> > The nice thing about tabs is that, as long as they're used 
> *consistently*
> ^^^^^^^^^^^^^^
> In my experience it just isn't possible to herd cats.  It's 
> *impossible*
> to get a group to use non-8-wide tabs consistently.
> 
> > and *well* (tab to indent code blocks, spaces if things need to be
> > indented to line up /within/ a code block), they can 
> satisfy everyone

I respect that.  I'm hoping we're different.  

> MS-DOG Edit simply refuses to let you mix tabs 

Hello?  This is 2002?  Anyone who sends me a patch full of 0x0D0A risks
being mocked to the end of time.  I'm likely to send it back as a pile of
wrinkled bits.  

> You simply can't count on *all* editors to preserve 
> whitespace exactly.

Maybe not, but if the maintainers don't mind running patches throught
indent(1) first, I don't think anyone's editor [mis]choice will cause
problems.  

> Personally I like the Linux coding standards, especially for its
rationales.

I think they're OK, in the Hippocratic sense: they won't hurt.  OTOH, some
of the rationale is a bit antique, don't you think?  That we should define
goodness of function size in terms of "ANSI" screens of 80x24?  Please.
Those days are gone and good riddance.  There was *never* a fundamental
human factors reason for that dimension; it was a function of the state of
the art of CRT technology, nothing more, nothing less.  

The other thing that boggles me is, if I do accept all the restrictions --
80x24 and tabstops of 8, no more than three indentations -- how much room do
I have even three stops in?  80 - (8 * 3) = 56.  That's not enough room to
use fprintf to write a decent error message.  Sure, you can jump through
hoops to shoehorn it in, but keep in mind what Emerson said about "foolish
consistency".  

Such rules are a little like "rules" of poetry.  They give the beginner a
sense of where to start, but a long time before you become Robert Frost,
they get in your way.  

> Besides, it's probably in the ANSI standard that tabs are as wide as 8
> spaces.  Anything else is like pretending pi to be 5.

Nonsense.  pi is a truth and tabstops aren't.  

> Anyway, as more editor-flamewar-fuel, I think vim is best for 
> hopping around
> between coding styles.  sw, ts and et can all be controlled 
> separately.  Try doing that with "Other OS" IDE editors.  :)

I keep telling myself I should learn emacs, and keep hoping nedit will grow
all the features I want, so I won't have to.  

Regards, 

--jkl


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.