Naming question

[evanevankan2]

Lets say I have an example structure like this

struct day {
/* Data goes here */
};

and in my program I work with an array of structs of that type.

Example:

int main(void)
{
struct day *day;
int count;

/* Allocation of struct goes here. */

do_stuff_on_array(day, count);
do_stuff_on_day(day);

return 0;
}

void do_stuff_on_array(struct day *day, int count)
{
int i;
for (i = 0; i < count; i++) {
/* Do stuff on day */
}
}

void do_stuff_on_array(struct day *day)
{
/* Do stuff on *day */
}

Now my question is just about the names. I always try to make up
the best describing names for my variables and structs, but I have
problems on which conventions I should use. I ended up with
the same name for both the variable and struct, that is 'day'.
So I write: struct day *day;
I know it works perfectly well because of different namespaces.
But is that a bad idea, would you say it is confusing to have the
same name?

Then the next question. The first parameter of the two functions
are idential, and I choose the same naming here too:
struct day *day
But the functions work on different things, the first one on
a whole array while the second only on an element.
Should I use some different naming here for the two functions
to indicate that they don't handle the argument in the same way,
in order to not confuse people who read my code?

Grateful for any opinions!
Thanks

 

[user923005]

Lets say I have an example structure like this

struct day {
    /* Data goes here */

};

and in my program I work with an array of structs of that type.

Example:

int main(void)
{
    struct day *day;
    int count;

    /* Allocation of struct goes here. */

    do_stuff_on_array(day, count);
    do_stuff_on_day(day);

    return 0;

}

void do_stuff_on_array(struct day *day, int count)
{
    int i;
    for (i = 0; i < count; i++) {
        /* Do stuff on day */
    }

}

void do_stuff_on_array(struct day *day)
{
    /* Do stuff on *day */

}

Now my question is just about the names. I always try to make up
the best describing names for my variables and structs, but I have
problems on which conventions I should use. I ended up with
the same name for both the variable and struct, that is 'day'.
So I write: struct day *day;
I know it works perfectly well because of different namespaces.
But is that a bad idea, would you say it is confusing to have the
same name?

Then the next question. The first parameter of the two functions
are idential, and I choose the same naming here too:
struct day *day
But the functions work on different things, the first one on
a whole array while the second only on an element.
Should I use some different naming here for the two functions
to indicate that they don't handle the argument in the same way,
in order to not confuse people who read my code?

A common convention is to use a _t suffix to define a type.
Hence something along these lines:

/* Make a type: */
typedef struct day_t {
int julian_val;
int hours;
int min;
int seconds;
int frac;
} day_t; /* Now you can declare a struct day_t or just a day_t */

/* Declare an instance of the type: */
day_t day;

 

[Ben Pfaff]

A common convention is to use a _t suffix to define a type.

This convention is not a good choice for programmers who wish to
write code that conforms to POSIX as well as to ISO C, because
POSIX reserves all file-scope identifiers that end in _t if any
POSIX header (including standard C headers) is included.

 

[Gregory Pietsch]

All of the comp.lang.c regulars have different styles. It's good to
check such guides as the Indian Hill Style Guide or even the GNU one.

I tend to put my structure tags and structure type definitions in
upper case and end them with _T so that they do not clash with
reserved names. For arrays, there's not much more that you'd want to
do with them as arrays than what's in the dynamic array code I've
written before, so I'd use that. The array type ends in _ARRAY_T.
Functions that would be methods to an object if I were writing C++
have a slug prefix that is consistent. Function names start with
verbs; "do", "perform", and other nebulous verbs aren't good. The verb
"is" is always followed by an underscore in a function name and
returns nonzero if the condition being tested is true, zero for false.
Ditto for "has", but I don't use "has" as much as "is". Such functions
do not have any word such as "not" in the name because the negation
tends to confuse simpletons who can't understand Boolean logic after a
round of alcoholic drinks.

Anything else?

Gregory