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

[Amarendra GODBOLE]

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.

My team is in the process of adding new features to this app. As a
start off, I asked them to write clean code, which conforms to certain
aspects of the ANSI standard. I am no authority on the standard, and
my knowledge is based on C Unleashed.

For that I asked them to --
1. Avoid identifier names starting with _.
I asked them to change the following structure --

typedef struct _foo {
...
} Foo;

to

typedef struct foo_ {
...
} Foo;

2. Avoid clashes with the system namespace. To avoid id names
beginning with str, is, etc.

I thought by making them aware of such issues, we can probably write
code which is more clean, easy to maintain, and partly conforming to
ANSI.

But they fail to see my point of conformance and I am faced with
issues like --
1. How will we trample the system namespace with names like
_DBGetFooRecord etc.
2. Standards etc are junk and in no way we are to conform to that. We
are going to write code the way _we_ feel it.

My defense was all that I have learned from C Unleashed, but it is
proving to ve weak. I'd like you all from clc to help me make my
defense stronger, so that I can make them see some light !

I am not sure if this mail is OT or OT (On or Off), but nevertheless I
am posting it.

Cheers,
Amarendra

[Jack Klein]

On 18 Jan 2004 20:45:44 -0800, ro**@zworg.com (Amarendra GODBOLE)
wrote in comp.lang.c:

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.

My team is in the process of adding new features to this app. As a
start off, I asked them to write clean code, which conforms to certain
aspects of the ANSI standard. I am no authority on the standard, and
my knowledge is based on C Unleashed.

For that I asked them to --
1. Avoid identifier names starting with _.
I asked them to change the following structure --

typedef struct _foo {
...
} Foo;

to

typedef struct foo_ {
...
} Foo;
Note that it is almost never necessary, or particularly helpful, to
provide both a structure tag and a typedef for a structure definition.
Don't do this unless you need it.
2. Avoid clashes with the system namespace. To avoid id names
beginning with str, is, etc.

I thought by making them aware of such issues, we can probably write
code which is more clean, easy to maintain, and partly conforming to
ANSI.

But they fail to see my point of conformance and I am faced with
issues like --
1. How will we trample the system namespace with names like
_DBGetFooRecord etc.
Maybe you will, maybe you won't. That's exactly the point, that
namespace is reserved for the language standard (__FILE__, and such)
and for the implementation, meaning the compiler and it's headers.

You can come up with some incredibly hard-to-find bugs when you try to
build your old code with a new compiler, or even a newer version of
your current compiler, and somewhere in the compiler internals or in
some private include file is a macro or intrinsic symbol that matches
one of your identifiers.
2. Standards etc are junk and in no way we are to conform to that. We
are going to write code the way _we_ feel it.
Is this a volunteer open source project or a commercial product? Are
you dealing with professional programmers or trying to teach a class
of crabby pre-schoolers?

One of the reasons for the incredible amount of defective software
today is the cowboy know-it-all attitude of far too many programmers.
Those who still see programming as an art and not as a science or
engineering discipline might be beyond help.

If the worked for me, they would change their attitudes or find
themselves looking for a new job.
My defense was all that I have learned from C Unleashed, but it is
proving to ve weak. I'd like you all from clc to help me make my
defense stronger, so that I can make them see some light !

I am not sure if this mail is OT or OT (On or Off), but nevertheless I
am posting it.

Cheers,
Amarendra

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[E. Robert Tisdale]

Amarendra GODBOLE wrote:

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

My team is in the process of adding new features to this application.
As a start off, I asked them to write clean code
which conforms to certain aspects of the ANSI standard.
I am no authority on the standard
and my knowledge is based on C Unleashed.

For that I asked them to --

1. Avoid identifier names starting with _.
I asked them to change the following structure --

typedef struct _foo {
...
} Foo;

to

typedef struct foo_ {
...
} Foo;
Ask them to write

typedef struct Foo {
// . . .
} Foo;

instead. There is no point in cluttering up the namespace.
2. Avoid clashes with the system namespace.
To avoid id names beginning with str, is, etc.

I thought by making them aware of such issues,
we can probably write code which is more clean, easy to maintain
and partly conforming to ANSI.

But they fail to see my point of conformance
and I am faced with issues like --

1. How will we trample the system namespace
with names like _DBGetFooRecord etc.
2. Standards etc. are junk and in no way we are to conform to that.
We are going to write code the way _we_ feel it.

My defense was all that I have learned from C Unleashed
but it is proving to be weak.
I'd like you all from clc to help me make my defense stronger
so that I can make them see some light!

Unless you are the team leader, you have no business doing so.
I'm not sure how you could be a team leader supervising C programmers
without a *strong* grasp on the ANSI/ISO C standards.

If you are just another team member, try listening instead of talking.
Try to learn from more experienced team members.
Beware of their bad habits and endeavor not to acquire them yourself.

[Richard Heathfield]

Jack Klein wrote:

On 18 Jan 2004 20:45:44 -0800, ro**@zworg.com (Amarendra GODBOLE)
wrote in comp.lang.c:

typedef struct foo_ {
...
} Foo;
Note that it is almost never necessary, or particularly helpful, to
provide both a structure tag and a typedef for a structure definition.
Don't do this unless you need it.

Fair comment, but I'd like to raise some points in its favour: 1) it can
make life easier for some code analysis tools; 2) it never hurts, provided
one has an even remotely decent naming convention for types; 3) it makes
opaque typing slightly easier; 4) if you do it /all/ the damn time, it's
there when you /do/ need it, without your having to think about what
changed.

<snip>

[Because of snippage, I should point out that the OP is railing against the
following attitude, not espousing it!]

2. Standards etc are junk and in no way we are to conform to that. We
are going to write code the way _we_ feel it.

Is this a volunteer open source project or a commercial product? Are
you dealing with professional programmers or trying to teach a class
of crabby pre-schoolers?

To me, they don't sound like either group. Rather, they're simply perfectly
normal C programmers who haven't yet discovered comp.lang.c. There are
quite a few of them out there, you know.
One of the reasons for the incredible amount of defective software
today is the cowboy know-it-all attitude of far too many programmers.
Those who still see programming as an art and not as a science or
engineering discipline might be beyond help.

I'll buy "and not", since I see it as an art /and/ a science /and/ a craft.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Nils Petter Vaskinn]

On Mon, 19 Jan 2004 08:24:13 +0000, Richard Heathfield wrote:

Jack Klein wrote:

One of the reasons for the incredible amount of defective software
today is the cowboy know-it-all attitude of far too many programmers.
Those who still see programming as an art and not as a science or
engineering discipline might be beyond help.

I'll buy "and not", since I see it as an art /and/ a science /and/ a
craft.

And a good artits would get the paint on the canvas not on the floor. It
is an art, but that doesn't mean all artist are good artists.

--
NPV

"the large print giveth, and the small print taketh away"
Tom Waits - Step right up

[pete]

Amarendra GODBOLE wrote:

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.

Is portability an issue ?
Is the software intended to run on only just one kind of machine,
which is exactly the same as the one that your testing with ?

If the answers are not no and yes respectively, then your case
is valid, and you need a more effective presentation,
as you have already stated.

If the answers are no and yes respectively, then maybe you should
just try to exert your influence again when the next project starts.
If portability is not a requirement now, and if that
requirement changes, then that's a new assignment for new money.

--
pete

[CBFalconer]

Jack Klein wrote:

ro**@zworg.com (Amarendra GODBOLE) wrote in comp.lang.c:

.... snip ...

typedef struct foo_ {
...
} Foo;

Note that it is almost never necessary, or particularly helpful, to
provide both a structure tag and a typedef for a structure definition.
Don't do this unless you need it.

<nit> If the "..." includes a "struct foo_ *id" field, it is
necessary. </nit>

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Darrell Grainger]

On Sun, 18 Jan 2004, Amarendra GODBOLE wrote:

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.

My team is in the process of adding new features to this app. As a
start off, I asked them to write clean code, which conforms to certain
aspects of the ANSI standard. I am no authority on the standard, and
my knowledge is based on C Unleashed.
What you are asking them to do is a lot of work with no visible benefit.
From a management point of view I would see this as making a lot of
changes when no actual change to what the code does. I'd be worried that
changing the code 'unnecessarily' will add risk. What if I decide to
change all the _foo to foo_ and there is aleady a foo_ in the system? I
cannot just change all the names without first checking that the new name
does not exist. In other words, you are probably facing a "if it ain't
broke, don't fix it" additude.

I believe Martin Fowler wrote a good book on refactoring. His reason for
refactoring was to make the code esier to maintain but I would guess that
a lot of what he has to say will apply to your situation as well. You are
basically refactoring the code. So go to some where like amazon.com and
search for Martin Fowler's book on Refactoring.

Additionally, you want to do this in stages. The budget might not handle
having everyone just refactoring for a few months. I'd guess that you will
still need to add functionality while refactoring.
For that I asked them to --
1. Avoid identifier names starting with _.
I asked them to change the following structure --

typedef struct _foo {
...
} Foo;

to

typedef struct foo_ {
...
} Foo;
Why? That is the question I always have to answer in order to get the
developers at my site to accept a new procedure. If it does not make sense
to them they will not do it. Additionally, they will often do things that
have benefit for them but not the organization as a whole. In those cases
they are usually not rewarded for refactoring the code. I need to get
management on side. Once management indicates they will reward developers
for refactoring the code they are more inclined to do it.
2. Avoid clashes with the system namespace. To avoid id names
beginning with str, is, etc.
Why? Wouldn't the compiler give a warning if I used a function name that
clashed with a system function? Then I'd know to change that. Think of
reasons they will feel your suggestions are not necessary and have
something to counter with.
I thought by making them aware of such issues, we can probably write
code which is more clean, easy to maintain, and partly conforming to
ANSI.
Do they get rewarded for cleaning up the code? Or is this coming across as
a punishment, e.g. everyone wrote bad code and now you are going to have
to clean it up.
But they fail to see my point of conformance and I am faced with
issues like --
1. How will we trample the system namespace with names like
_DBGetFooRecord etc.
2. Standards etc are junk and in no way we are to conform to that. We
are going to write code the way _we_ feel it.

My defense was all that I have learned from C Unleashed, but it is
proving to ve weak. I'd like you all from clc to help me make my
defense stronger, so that I can make them see some light !
It all boils down to what is the benefit. Show them examples of how things
can go wrong. Also, be open to the fact that this might take time. Also,
consider the market. Can they afford to refactor the code? Is there so
little profit that they cannot afford the extra work? If you try to get
them doing everything at once you will get nothing. Try a little at a
time.
I am not sure if this mail is OT or OT (On or Off), but nevertheless I
am posting it.

Cheers,
Amarendra

--
Send e-mail to: darrell at cs dot toronto dot edu
Don't send e-mail to vi************@whitehouse.gov

[E. Robert Tisdale]

Richard Heathfield wrote:

Jack Klein wrote:

Note that it is almost never necessary, or particularly helpful, to
provide both a structure tag and a typedef for a structure definition.
Don't do this unless you need it.
Fair comment, but I'd like to raise some points in its favor:
1) it can make life easier for some code analysis tools;
2) it never hurts, provided that
one has an even remotely decent naming convention for types;

I pollutes the namespace unnecessarily.
3) it makes opaque typing slightly easier;
4) if you do it /all/ the damn time, it's there when you /do/ need it,
without your having to think about what changed.

typedef struct Foo {
struct Foo* p;
// ...
} Foo;

or better yet:

typedef struct Foo Foo;
struct Foo {
Foo* p;
// ...
};

[Michael Wojcik]

In article <Pi*******************************@drj.pf>, da*****@NOMORESPAMcs.utoronto.ca.com (Darrell Grainger) writes:

Why? Wouldn't the compiler give a warning if I used a function name that
clashed with a system function? Then I'd know to change that.

It's not clear to me whether you meant this as a serious objection to
rewriting code to avoid the implementation namespace, or only as a
proleptic example of an objection someone else might raise. In any
event, it's easily dealt with. There's no reason to believe the
implementation *would* warn you if you defined a function using a
name from the implementation namespace. In itself that doesn't violate
a constraint.

If there's a prototype in scope for a function of that name, and your
function doesn't match it, then yes, you ought to get a diagnostic
(C90 6.3.2.2 constraint). And it's certainly possible in some cases
for an implementation to note when a translation unit invades the
implementation namespace and issue a diagnostic - but I can't think
of any I've used that do.

Just the other day I had to correct some old code that stepped fatally
on an implementation-defined function. The function name in question
wasn't a reserved one, but it was a "system function" (provided by the
implementation). No diagnostic was issued during compilation, and the
implementation - gcc + glibc, on a relatively recent Linux distribution
- is a popular one.

--
Michael Wojcik mi************@microfocus.com

Proverbs for Paranoids, 1: You may never get to touch the Master,
but you can tickle his creatures. -- Thomas Pynchon

[Richard Heathfield]

E. Robert Tisdale wrote:

Richard Heathfield wrote:

Jack Klein wrote:

Note that it is almost never necessary, or particularly helpful, to
provide both a structure tag and a typedef for a structure definition.
Don't do this unless you need it.
Fair comment, but I'd like to raise some points in its favor:
1) it can make life easier for some code analysis tools;
2) it never hurts, provided that
one has an even remotely decent naming convention for types;

I pollutes the namespace unnecessarily.

If one has an even remotely decent naming convention for types, then this
"pollution" is immaterial.

3) it makes opaque typing slightly easier;
4) if you do it /all/ the damn time, it's there when you /do/ need it,
without your having to think about what changed.

typedef struct Foo {
struct Foo* p;
// ...
} Foo;

This can confuse some code analysis tools (e.g. Visual Studio's "go to
definition" feature won't know which Foo you mean).
or better yet:

typedef struct Foo Foo;
struct Foo {
Foo* p;
// ...
};

Same applies.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[E. Robert Tisdale]

Richard Heathfield wrote:

E. Robert Tisdale wrote:

Richard Heathfield wrote:

Jack Klein wrote:

Note that it is almost never necessary, or particularly helpful, to
provide both a structure tag and a typedef for a structure definition.
Don't do this unless you need it.

Fair comment, but I'd like to raise some points in its favor:
1) it can make life easier for some code analysis tools;
2) it never hurts, provided that
one has an even remotely decent naming convention for types;
I pollutes the namespace unnecessarily.

If one has an even remotely decent naming convention for types,
then this "pollution" is immaterial.

3) it makes opaque typing slightly easier;
4) if you do it /all/ the damn time, it's there when you /do/ need it,
without your having to think about what changed.

typedef struct Foo {
struct Foo* p;
// ...
} Foo;

This can confuse some code analysis tools (e.g. Visual Studio's "go to
definition" feature won't know which Foo you mean).

I don't think that it is a good idea to cobble your code
just to accommodate some defective tool.

or better yet:

typedef struct Foo Foo;
struct Foo {
Foo* p;
// ...
};

Same applies.

[Jack Klein]

On Mon, 19 Jan 2004 08:24:13 +0000, Richard Heathfield
<in*****@address.co.uk.invalid> wrote in comp.lang.c:

Jack Klein wrote:

On 18 Jan 2004 20:45:44 -0800, ro**@zworg.com (Amarendra GODBOLE)
wrote in comp.lang.c:

typedef struct foo_ {
...
} Foo;

Note that it is almost never necessary, or particularly helpful, to
provide both a structure tag and a typedef for a structure definition.
Don't do this unless you need it.

Fair comment, but I'd like to raise some points in its favour: 1) it can
make life easier for some code analysis tools; 2) it never hurts, provided
one has an even remotely decent naming convention for types; 3) it makes
opaque typing slightly easier; 4) if you do it /all/ the damn time, it's
there when you /do/ need it, without your having to think about what
changed.

<snip>

[Because of snippage, I should point out that the OP is railing against the
following attitude, not espousing it!]

2. Standards etc are junk and in no way we are to conform to that. We
are going to write code the way _we_ feel it.

Is this a volunteer open source project or a commercial product? Are
you dealing with professional programmers or trying to teach a class
of crabby pre-schoolers?

To me, they don't sound like either group. Rather, they're simply perfectly
normal C programmers who haven't yet discovered comp.lang.c. There are
quite a few of them out there, you know.

Sadly I agree with you, as far as your statement goes, which is not
far enough. Rather they are simply typical programmers in any
language. There are many more sources of enlightenment than just
comp.lang.c, or all of usenet.

Although it is not entirely the fault of the programmers. The
educational systems of many countries, including the US, is sadly
deficient. And the priorities of far too many businesses are
inappropriate as well.

One of the reasons for the incredible amount of defective software
today is the cowboy know-it-all attitude of far too many programmers.
Those who still see programming as an art and not as a science or
engineering discipline might be beyond help.

I'll buy "and not", since I see it as an art /and/ a science /and/ a craft.

Simply put, computer programming is still too new a field. It is not
possible to do thorough analysis, nor to pass truly objective
judgement.

No educational institution would give a graduate a medical degree
without a demonstrated understanding of anatomy. Nor a structural
engineer without a thorough and proven grounding in the objective
standards of the field.

But they think nothing of giving people computer science or
engineering degrees who think that this is proper and correct:

#include <stdio.h>
#include <conio.h>

void main(void)
{
printf("Hello, World\n");
getch();
}

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Amarendra GODBOLE]

[...snipped...]

It all boils down to what is the benefit. Show them examples of how things
can go wrong. Also, be open to the fact that this might take time. Also,

[...snipped...]

Thanks folks. All replies have definitely given me a direction to work
on. Here is what I have decided to do:
1. Listen more.
2. Be more knowledgable about the ANSI/ISO C standard.
3. Think from all angles, especially from the management perspective
too.
4. Trouble you all, if things are hazy still !

BTW, I am a team member, and my effort was in a direction of making
other programmers' aware of --
1. Standardization and its benefits.
2. ANSI/ISO C standards.
3. comp.lang.c (They are not aware that this exists !)
4. Initiate a thought process on writing better and more maintainable
code.

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.

Thanks a lot to comp.lang.c

Cheers,
Amar

--
Destiny is not a matter of chance, it is a matter of choice.

[E. Robert Tisdale]

Amarendra GODBOLE wrote:

Here is what I have decided to do:
1. Listen more.
2. Be more knowledgeable about the ANSI/ISO C standard.
3. Think from all angles,
especially from the management perspective too.
4. Trouble you all, if things are hazy still!

BTW, I am a team member and my effort was in a direction of making
in a direction of making other programmers' aware of --
1. Standardization and its benefits.
2. ANSI/ISO C standards.
3. comp.lang.c (They are not aware that this exists!)
4. Initiate a thought process
on writing better and more maintainable code.

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.

"A scientific truth does not triumph by convincing its opponents
and making them see the light,
but rather because its opponents eventually die
and a new generation grows up that is familiar with it."
-- Max Planck

Our profession is evolutionary -- not revolutionary.
It must wait for the Olde Tymers to retire (or die)
before it can advance. Be patient.

[Christian Bau]

In article <89**************************@posting.google.com >,
ro**@zworg.com (Amarendra GODBOLE) wrote:

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.

I'll give you a few advantages of writing Standard C code that are not
mentioned too often, and they come purely from a management/time savings
perspective:

1. If your code base is Standard C, then _any_ C programmer can
understand the code. You might be writing code for an embedded system
that I haven't even heard of; if it is Standard C then _I_ can read your
code, understand it, find bugs etc. If it is not Standard C but specific
to that implementation, then you have to find someone how knows all
those specifics.

2. There is lots of code where the programmer thinks "it might be
undefined behavior, but it works". That's fine if your program works.
What if there are bugs, and someone has to fix the problem? If there are
no obvious problems in the code, but it doesn't work, then obviously
there must be hidden problems. So I look for suspicious things and fix
them. Guess what: Every bit of undefined behavior, even if it works,
causes me to do extra work at debugging time.

3. It is not only important that your code is good, it is also important
that people have confidence in it. If I look at 10,000 lines of code
that I haven't seen before, and I find three cases of undefined behavior
in the first 50 lines, then I don't trust this code. That fact alone
will cost time and money. For example, code that is badly written must
be tested more thouroughly and that costs money again.

4. When reading code, everything that interrupts the flow costs time.
And programmers read a lot of code. Bad programming style interrupts the
flow. Code that would create warnings if the programmer hadn't turned
all warnings off interrupts the flow. Undefined behavior certainly
interrupts the flow.

[CBFalconer]

Amarendra GODBOLE wrote:

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

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Richard Bos]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:

Richard Heathfield wrote:

E. Robert Tisdale wrote:

typedef struct Foo {
struct Foo* p;
// ...
} Foo;

This can confuse some code analysis tools (e.g. Visual Studio's "go to
definition" feature won't know which Foo you mean).

I don't think that it is a good idea to cobble your code
just to accommodate some defective tool.

And for once, I agree with Mr. Tisdale. I want my code to be easy for
_me_ to read. If the computer can't make sense of perfectly correct
code, it's time to get another program.

Richard

[Richard Heathfield]

Richard Bos wrote:

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:

Richard Heathfield wrote:

> E. Robert Tisdale wrote:
>
>>typedef struct Foo {
>>struct Foo* p;
>>// ...
>>} Foo;
>
> This can confuse some code analysis tools (e.g. Visual Studio's "go to
> definition" feature won't know which Foo you mean).
I don't think that it is a good idea to cobble your code
just to accommodate some defective tool.

And for once, I agree with Mr. Tisdale.

Well, I don't think I'm cobbling the code; I think I'm making it more
readable, for me at least. As it happens, I rarely use Visual Studio at
home (which is the only place my coding conventions apply, unless I'm
fortunate enough to work at a site where they either use my conventions
already or are prepared to change them for my benefit!) - but my convention
/does/ have the benefit of being easier for Visual Studio to sort out
(incidentally, if the tag and the typedef /are/ the same, Visual Studio
asks which you mean, so I think it's probably unfair to call it "defective"
in this regard, at least).
I want my code to be easy for
_me_ to read. If the computer can't make sense of perfectly correct
code, it's time to get another program.

My convention is:

struct Foo_
{
...
};

typedef struct Foo_ Foo;

I do not find this hard to read.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[pete]

Richard Heathfield wrote:

Richard Bos wrote:

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:

Richard Heathfield wrote:

> E. Robert Tisdale wrote:
>
>>typedef struct Foo {
>>struct Foo* p;
>>// ...
>>} Foo;
>
> This can confuse some code analysis tools (e.g. Visual Studio's "go to
> definition" feature won't know which Foo you mean).

I don't think that it is a good idea to cobble your code
just to accommodate some defective tool.

And for once, I agree with Mr. Tisdale.

Well, I don't think I'm cobbling the code; I think I'm making it more
readable, for me at least.

My convention is:

struct Foo_
{
...
};

typedef struct Foo_ Foo;

I do not find this hard to read.

I don't like the type having the exact same spelling as the object,
either.

--
pete

[Eric Sosman]

Amarendra GODBOLE wrote:

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.

--
Er*********@sun.com

[Dan Pop]

In <40******@news2.power.net.uk> Richard Heathfield <in*****@address.co.uk.invalid> writes:

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Randy Howard]

In article <40***************@yahoo.com>, cb********@yahoo.com says...

Amarendra GODBOLE wrote:

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

--
Randy Howard
2reply remove FOOBAR

[Dan Pop]

In <40***************@sun.com> Eric Sosman <Er*********@sun.com> writes:

Amarendra GODBOLE wrote:

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?

"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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Richard Heathfield]

Dan Pop wrote:

In <40******@news2.power.net.uk> Richard Heathfield
<in*****@address.co.uk.invalid> writes:

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.

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;
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Dan Pop]

In <40******@news2.power.net.uk> Richard Heathfield <in*****@address.co.uk.invalid> writes:

Dan Pop wrote:

In <40******@news2.power.net.uk> Richard Heathfield
<in*****@address.co.uk.invalid> writes:

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.

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de