Skip to Content.
Sympa Menu

freetds - RE: [freetds] coding style choices

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO Frediano" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] coding style choices
  • Date: Tue, 4 Nov 2003 11:16:17 +0100

> >
> > > if (cd != (iconv_t)-1)
> >
> > Usually I use indent to fix style, I think indent is the
> > problem... IMHO
> > anyone should indent(1) all code before commit... perhaps a
> > perl script
> > to fix some strange formattings (like - 1 instead of -1) should be a
> > good solution ... I know a big perl guru :)
>
> I dunno, Freddy. indent(1) is a tool; I don't want to be a
> slave to it. It
> really helps bring mangled code into good form, but it's not human.
> Sometimes I wrap lines in ways that I think are clear but
> that indent would
> redo.
>

I know but helps my to keep my code in a good state.
Using many editors (from vim under Linux, anjuta, an older vi under
HP/UX, Dev/C++, VC6 under windows for testing...) indent help me very
much.

> > > static const iconv_t INVALID_DESCRIPTOR = (iconv_t)-1;
> >
> > IMHO is better a #define for portability problems...
>
> I don't foresee any portability problem. It's one line of ANSI C. If
> you're right, though, it's easy to change to a #define.
>

I'm too syntetic... Some (old) compilers allocate space for this
constant for ever module that declare the constant so I prefer #define.

> > > /*
> > > * Multiline comments are formatted like this,
> > > * and phrased as sentences.
> > > */
> >
> > We already use a similar format... I don't understand the
> > difference...
>
> /* some of our comments
> * look like this */
> and
> /* some of them are a series */
> /* of single-line comments */
>
> but
> /*
> * I like this way best, and
> * I don't think indent(1) will help us here.
> */
>

I see.. I'd like also single line comment ( /* comment */ ).
Personally I dislike boxing like

/**************************************
* comment
**************************************/

IMHO you can fill doc/CodingStyle with new comment style.


> > About ODBC formatting. We have attribute like henv, hdbc
> that are just
> > pointers, not handles. I'd like to remove "h" from name. Another are
> > attributes.
>
> A handle is a way for a calling function to denote an object
> it doesn't
> manage. It's up to the manager how to decode a handle. It may be a
> pointer, an index into a pointer array, or something else.
>
> In deciding whether or not to remove the 'h', I suggest you
> consider how
> other ODBC hackers are used to thinking about these things.
> Then adopt the
> Principle of Least Surprise.
>

I know that this simple change change many lines however the handle
prefix "h" came from former versions where these attributes are declared
as void * and odbc.c contained much more casts. Now are typed correctly
so "h" prefix is no more correct. However I'll wait some days for
comments.

> > There are a structure with all attribute with
> > names starting
> > with "attr_". Perhaps is better to remove these attr structure and
> > incorporate attributes in _hdbc/_henv/_hstmt.
>
> Your call. Sounds right to me.
>

I'd like to change this stuff before 0.62 cause this code was added
after 0.61. I don't like lines like

dbc->attr.attr_autocommit = state;

I prefer something like

dbc->attr_autocommit = state;

freddy77




Archive powered by MHonArc 2.6.24.

Top of Page