FreeTDS Development Group

["James K. Lowden" <jklowden AT schemamania.org>]

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