[Maybe OT] How to convince people about the importance of ANSI standards conformance ?

[Dan Pop]

My convention is:

struct Foo_
{
...
};

typedef struct Foo_ Foo;

I do not find this hard to read.

Not using typedefs for structs makes the code even easier to read.

When you have to use them, because the struct is actually the
implementation of an ADT, it's better to follow the <stdio.h> example
and spell the ADT name in all caps:

typedef struct foo FOO;

Dan

 

[Eric Sosman]

Hi,

I am working on a legacy user space app, which has been developed
entirely in C, some 15 years ago. Needless to say, it does not even
partially conform to any standard.

"Some fifteen years ago?" That would be, let's see,

2004
-15
____
1989

Now, where have I seen that number before? Ah, yes: it
was the adoption date of the very first C Standard, the one
that gave rise to the still-used moniker "ANSI C." Why in
the world would new code being written in that year fail to
take the new Standard into account?

Aha! It's now January, and in January of 1989 the not-
yet-Standard was still in draft form (still with `noalias')
and had not yet been formally adopted. So it's entirely
understandable that your programmers chose to ignore it; it
was a whole ten months in the future, after all, so what
difference could it make? Why slow down the slash-and-burn
coding effort by wasting thought on the remote future?

True, it was the case in 1989 and even for three or four
years thereafter that Standard-conforming implementations
were less widely available and more bug-ridden than one could
have hoped. Still, even those of us who will never be called
geniuses could see that conforming implementations were on
the way and would be Good Things when they arrived -- and
we started writing in such a way as to be ready when the
Great Day dawned. The original authors of your code seem to
have chosen to sleep through that dawn; perhaps they were the
spiritual kindred of those who, to this day, inveigh against
the updated C99 Standard.

 

[Randy Howard]

[...snipped...]

The path that I chose initially was probably asking too much
of them, without really showing them what the benefits are.
I surely need to re-visit that, and rebuild my case in a more
proper way.

There is hope for this one. In a day or two he has gone from
insufferable to a cooperative teachable human being, with
leadership qualities.

Yes, the force is strong within that one.

One point that I don't recall having seen in this thread, is
that Amarendra never indicated that he was either the manager,
or the technical lead for the project. Without one or both
of those positions, it's usually not within another team
member's power to make such requirements *directly*.

Instead of trying to convince the whole group, focus on the tech
lead privately. Hint: IF you let the head honcho pretend like
it is his/her idea, it's far, far more likely to happen. It
shouldn't be like that, but more often than not, it simply is.

Another method, which may take a lot longer, is to keep metrics
and simply write your own code more strictly, then you can
hope to observe bug rates being lower in conforming code than
elsewhere. It might not happen for this project, but people
will start to come around if your code is habitually the
least buggy.

 

[Dan Pop]

"Some fifteen years ago?" That would be, let's see,

2004
-15
____
1989

Now, where have I seen that number before? Ah, yes: it
was the adoption date of the very first C Standard, the one
that gave rise to the still-used moniker "ANSI C." Why in
the world would new code being written in that year fail to
take the new Standard into account?

"Some fifteen years ago" could also mean 13 or 17 years ago...
He didn't put the "some" for the sole reason of increasing the word
count of his post by 1.

Aha! It's now January, and in January of 1989 the not-
yet-Standard was still in draft form (still with `noalias')
and had not yet been formally adopted.

Nope, noalias was already gone in the last public draft from 1988
(X3.???-1988). There is no trace of it in the first printing of
K&R2, either.

Dan

 

[Richard Heathfield]

In <[email protected]> Richard Heathfield


Not using typedefs for structs makes the code even easier to read.

I don't agree with you here; the struct keyword is IMHO unnecessarily
verbose...

When you have to use them, because the struct is actually the
implementation of an ADT, it's better to follow the <stdio.h> example
and spell the ADT name in all caps:

typedef struct foo FOO;

....but here I do agree with you, except that I would use:

typedef struct FOO_ FOO;

 

[Dan Pop]

I don't agree with you here; the struct keyword is IMHO unnecessarily
verbose...

Verbosity that results in improved code readability, if the typedef line
is burried deep in some header (as is usually the case for non-toy
programs) instead of being right above the relevant object declaration
(as is usually the case for toy/example programs).

Dan