FreeTDS Development Group

["Castellano, Nicholas" <Nicholas_Castellano AT acml.com>]

Sounds great to me.

You can't maintain symlinks or hard links in CVS.

It's probably good enough to keep one copy in the top-level source directory
of the CVS tree.  When actually doing the indent, you would need to copy
this to ~/.indent.pro or put a copy in each directory to be indented.
Really, there should be no need for "normal" users or even for most
developers to use this, so including it in CVS would actually be more a form
of documentation than anything else.

I suppose you could keep one copy in the top-level directory and have
Makefile rules pull it into each directory if the top-level one is newer.
But I suspect that wouldn't interact well with setups to build in an object
directory outside the source tree.

I'm actually slightly more pedantic than indent in the "case" case that you
cite.  Not only would I indent it as shown, but I would also add the missing
"break;" after each return.  So I think this is a step in the right
direction.

One issue where I've pretty much kept my mouth shut up until now...but this
is the time to bring it up, if ever.  Before we do this mass indent, I'd
like to put in one small plea that we rethink one of our indentation
standards.  I really prefer that local variables inside functions be
indented at the same level as code, instead of out at the margin with the
function declaration.  I find our current style really difficult to scan, as
my eye wants to treat these variables as K&R-style argument declarations.  I
don't want to make a big deal out of this, though...if Brian insists that we
keep this nonstandard indentation going forward, then I'll just live with
it.

Cheers,
--nick

-----Original Message-----
From: bounce-freetds-145195 AT franklin.oit.unc.edu
[mailto:bounce-freetds-145195 AT franklin.oit.unc.edu]
Sent: Saturday, October 19, 2002 12:46 PM
To: TDS Development Group
Subject: [freetds] indent(1) bent


Following up on an earlier threat, I worked up a profile for indent that
we can use to correct the sometimes haphazard format of our .c files.  You
my peruse it at:

http://www.SchemaMania.org/projects/freetds/src/.indent.pro
also an updated uncommited feckless style guide:
http://www.SchemaMania.org/projects/freetds/doc/CodingStyle

if you're interested.  

Issues great and small
----------------------

indent(1) relies on .indent.pro in the source code directory.  There's no
such thing as "for the project".  Two ideas to provide consistency
throughout the tree:

        1. keep one file in src and a symlink to it from eg src/dblib, or  
        2. generate them with automake or something.  

Suggestions solicited.  I'm not sure how well symlinks will persist
through "make dist", tar, and cvs.  Hard links, perhaps?  

I am relying on

        $ gindent --version
        GNU indent 2.2.6

which has two implications.  First, it defaults to GNU standards, which
IMO is fine (it's very tweakable).  Second, "indent *.c" does the right
thing.  Its grandfather, BSD indent, was just weird.  

I have run it over dblib.c and convert.c and am mostly happy with the
results.  Try it yourself, please, and see what you think.  (Hint: use -st
to route the output to stdout.) 

switch() is normally handled fine, nicely even, except in this sort of
case:

    switch (dbprocess->tds_socket->minor_version) {
    case 2:     return DBTDS_4_2;
    case 6:     return DBTDS_4_6;
    default:    return DBTDS_UNKNOWN;

no matter what I do, that becomes:

   switch (dbprocess->tds_socket->minor_version) {
   case 2:
        return DBTDS_4_2;
   case 6:
        return DBTDS_4_6;
   default:
        return DBTDS_UNKNOWN;
                
which is just a little pendantic for my tastes, and IMO no clearer.  Oh,
well.  

Committing.  Please DO NOT COMMIT any indent-related changes at this time.
 Bill Thompson sent us a big messy patch which we're both glad to have and
hope he'll unmessify.  Formatting changes in cvs at this particular stage
would complicate matters enormously.  

Going forward, I suggest indent(1) be used as a separate step in the
commit process.  Run it on the HEAD revision, and apply the results
(assuming you like them) as a separately commited revision with
"indent(1)" as the entire cvs log entry for it.  That way, it will be
easier to spot in the log.  The only edits you'd want would be to prevent
indent from affecting some section of code (bracketed by  *INDENT-OFF* and
*INDENT-ON*).  

Some folks like to try to time reformatting changes vis a vis a release. 
I think it's more like washing the dishes:  sometimes, you just have to do
it.  

Regards, 

--jkl

---
You are currently subscribed to freetds as: [Nicholas_Castellano AT acml.com]
To unsubscribe, forward this message to
$subst('Email.Unsub')


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.