Skip to Content.
Sympa Menu

freetds - Re: indent(1) bent

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Bernd Jendrissek <berndj AT prism.co.za>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: indent(1) bent
  • Date: Wed, 23 Oct 2002 23:19:17 +0200


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. It ends up looking
like this:

/* 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");
}
}

On Wed, Oct 23, 2002 at 06:43:25PM +0200, Steve Langasek wrote:
> On Wed, Oct 23, 2002 at 10:43:42AM -0400, Lowden, James K wrote:
> > 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.

edit != render. cat, less and grep are all common ways for me to look at
code. I don't want to specify 42 options or 17 pipes each time I just want
to peek at some code!

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

Tabs might be a feature, but they've been implemented in so many different
ways that they're just about useless unless you control their meaning
ruthlessly. Prefer a different indentation to what the coding standard
specifies? Run it through indent forwards, edit, then backwards.

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

With vim's cindent it's even more dopey: you don't press tab *at all* and
it's all but impossible to unindent while inserting. (Hint: ^D). You can
press backspace 400 times and it won't take even a bite out of the indent!

> > 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] }
^^^^
that's 4
>
> > which, btw is why God intended tabstops to be at 3. ;) My assertion is,

Why on earth would it be 3?

> > 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.
>
> God's own tabwidth is four, I tell you.

No, it's 8. Death to the unholy!

> 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 agree in principle, but the variations in editors prevent this being
implemented. MS-DOG Edit simply refuses to let you mix tabs and spaces at
the beginning of a line. IIRC it "unexpands" leading whitespace, converting
as much of it to tabs before reverting to spaces. You have no control over
the tab-width. (Again, IIRC. It's been a long time.)

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

> regardless of tabwidth preference. But if the basic rules aren't
> followed, it's certainly more of a mess than if people were just using
> spaces. :)

Quite. Pity that the "basic rules" simply *cannot* be followed 100%. I've
resigned myself to just being able to deal with code indented to any level.
Dense sw=2 stuff the Java guys here at work use, to Linux's sw=8 K&R-like
stuff. Personally I like the Linux coding standards, especially for its
rationales.

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.

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

bernd




Archive powered by MHonArc 2.6.24.

Top of Page