Re: How to pass a struct to a function

On 28 Mar, 22:49, Keith Thompson wrote an excellent article,
most of which I agree with, containing a few items on
which I'd like to comment:


(There's another common style that uses a typedef to give a structure
type a one-word name, but I won't get into that here.)

Ack..I'll go into it. I used to always typedefs structs, and
in retrospect I believe it was simply because I didn't understand
the syntax well enough to realize it was unnecessary. Personally,
I find typedef'ing a struct to be a heinous act which should
NOT be done. Declarations of the form "FOO a;" are hardly
clearer than "struct foo a;", and it is impossible to tell
from "FOO a" whether a is a pointer or not--you need to
go look at the typedef. Sometimes it is appropriate to
typedef a struct, but usually it is not.


fp = fopen("AppData.dat", "a"); /* open file for writing */

You're opening the file for appending, not just writing. Either
mention that in the comment, or just drop the comment; any reader who
doesn't know what fopen() does is going to have bigger problems.
Comments like that are ok if you're trying to convince someone that
you know what you're doing, but they're not useful in providing actual
information to the reader.

I disagree that such a comment is "OK". When I see
comments such as that, I tend to think that the
programmer in fact doesn't know what (s)he's doing.
If you happen to have a line of the form:
"data_fp[0] = fopen(data_path[4], "r");", then it would
be appropriate to add a comment explaining why
the fourth data file is being opened on the
zeroth file pointer, but completely pointless comments
serve to show a lack of knowledge on the part of
the programmer. Note that this should NOT serve
as a reason to avoid commenting your code. I have
often been very happy to see comments of the form:
/*
* I'm doing the following because I believe this will
* have this effect..., but I'm not entirely sure.
*/
(These are usually my own comments, BTW). When I
find comments like that, I know that the reason the code
looks a little weird is because the author was
in fact uncertain. There's nothing more annoying
than coming accross a section of arcane code that
you spend 40 hours analyzing only to discover that
it could have easily been re-written in 3 lines
and that all of the side-effects were in fact
totally unnecessary baggage that resulted from
a poor original design. Those 40 hours would
have been saved if a simple comment had been there
stating that the author was clueless and the
code should be redesigned from scratch.

Also annoying is the style which includes:
} /* end of i loop */
If your block is so large that you can't see the
opening brace, a comment doesn't fix the problem.

--
Bill Pursell

.

Relevant Pages

  • Re: Process dump facility public API - pdpublic.h
    ... struct _PDOPTIONS *pSystemDefaults; /* Ptr to System Defaults struct */ ... typedef DDPREQUEST *PDDREQUEST; ... also be specified in the DDPREQUEST flags. ... /* PDUNION is used in both the PDPROCESS and PDPROCESS2 structures. ...
    (comp.os.os2.bugs)
  • Re: advantage of using typedefs
    ... The underlying problem / solution here is "abstraction". ... struct, ... possible to call this with a length or pressure measurement by ... typedef double temperature; ...
    (comp.lang.c)
  • Re: [RFC][PATCH 1/5] Virtualization/containers: startup
    ... This patch introduces some abstract container/VPS kernel structure and tiny ... It's a _mistake_ to use typedef for structures and pointers. ... Again - there needs to be a _reason_ for this. ... In general, a pointer, or a struct that has elements that can reasonably ...
    (Linux-Kernel)
  • Re: syntax errror
    ... >>> int maxGrey' ... >> declaration of maxGrey. ... typedef double; ... struct some_tag_name { ...
    (comp.lang.c)
  • Re: question about struct??
    ... It is not the "typedef" keyword that defines the type. ... is the "struct {" pair that does it: ... struct S {int a; int b;}; ...
    (comp.lang.c)