FreeTDS Development Group

[Bernd Jendrissek <berndj AT prism.co.za>]

On Thu, Oct 24, 2002 at 10:06:10AM -0400, Lowden, James K wrote:
> > From: Bernd Jendrissek [mailto:berndj AT prism.co.za]
> > Sent: October 23, 2002 5:19 PM

[...]

> > > >      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;

[Interjection]  What happens *when* you want to add another statement if
0 == 1?  You'd need to *remember* to add the braces, if your editor can't
auto-indent as you type.  Putting in the braces now prevents bugs later,
and as a bonus it keeps the diffs slightly smaller.  Neither the if nor
the else would have differences.

>       else {
>          for (j=0; j < 10; j++) {
>             yay4jay();
>             alpha = omega;
>          }
>       }

Ah, I see.  I thought you meant for stuff like

if (very_long_condition("long conditions are another argument") &&
    some_more == 0) {
}

> 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. :)

Actually, I sympathise somewhat.  Kernel code is very different to database
interface code.  Kernels are *supposed* to be straightforward, pretty much
linear.  System call say "do this", you do exactly that.

> > 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.  

C:\> date
The current date is: Tue 1/1/1980
Enter the new date: (mm-dd-yy)

Okay, okay, I was being ridiculous.  But that doesn't mean software vendors
are incapable of still producing yet more just as ridiculous editors!

And yes, 0d 0a is a pain!  Especially when you dual-boot and access source
files from the "other" partition.  cvs import and you'll *never* get rid of
them.  (I usually just dos2unix the ,v files - we hardly ever look at
history anyway.)

> > 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.  

You could define away the problem and say that what indent(1) does is law.
In fact I suspect you can get CVS to reject incorrectly formatted files.
(Look at commitinfo in CVSROOT.)  CVS could then run a script which does:

save file to foo=`mktemp /tmp/indent-orig.XXXXXX`
copy $foo to bar=`mktemp /tmp/indent-done.XXXXXX`
cmp $foo $bar and exit with its $?

You'll be glad indent(1) has /* INDENT-OFF */ soon though.

> > 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

Yes.  For kernels I think they're positively *good*.

> 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.

Maybe 80x24 terminals are gone, but desktops with 4 files open and visible
aren't.  174x60 is about the biggest I can reasonably make an xterm here.
1042x390 if I use xterm's "Unreadable" font.  (Nice for gnuplot.)

Divide that by 4 and you get 87x30 (or 521x180:).  Pretty close to 80x24.

> 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.  

Railway lines are as far apart as they are because that's how close you can
get horses next to each other?  BTW why *is* it 80, and not 64, say?  And 24?

> 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".  

Sure.  It's probably a 2-of-3 choice.  Vertically dense, readable, narrow.
Choose any two.  I'd also ditch the "narrow" first.

> 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.  

#define TABSIZE 8.0

int main()
{
        double apx = 0.0;
        int i, sign;

        sign = 1;
        for (i = 0; ; i++) {
                printf("%f\n", apx);
                apx += sign * TABSIZE / (2 * (i * 2 + 1));
                sign = -sign;
        }
}

ts=8 is as true as pi.  :)

bernd