naming convetions

[Jyrgen]

Hi
I have problems giving my structs good names, I usually name
them after what they are (of course) so if I have, say, a
window struct, I name it struct window, I usually don't bother
typedefing them. But now I can't use the window as variable name
(yes, I know I *can*, but I won't, I don't want to be confused
by using the same name for both struct and variable).
I can use the name w for the variable in functions that do
operations on the window, that works, but if I add a struct
widget, I don't want that to also have the name w in function.
I want to be consistent in my variable naming in the function
arguments, and it would be confusing to use w for both windows
and widgets. Of course I can just use wt or anything as a
variable name, but I thought maybe I should change the
name of the struct so that I can freely choose the names of
the variables.
Maybe prefixing or postfixing the structname, I've seen
names ending with _t for type, but that violates the standard,
right? Maybe _s is a good choice?

So what I'm asking for is your opinions on how I should name
things. I understand that there are many different styles and
tastes of this, and that I have to choose myself, but I'll
gladly take any opinions from you. I want to know if there is
any common or pouplar way to name things. Thank you!na

 

[Richard Heathfield]

Jyrgen said:

Hi
I have problems giving my structs good names, I usually name
them after what they are (of course) so if I have, say, a
window struct, I name it struct window, I usually don't bother
typedefing them. But now I can't use the window as variable name
(yes, I know I *can*, but I won't, I don't want to be confused
by using the same name for both struct and variable).

Consider using the fact that C is case sensitive. Alternatively, consider
adding in the purpose of the object as part of its name. For example:

struct window main_window;
struct window edit_window;
struct window logging_window;

etc.

 

[August Karlstrom]

I have problems giving my structs good names, I usually name
them after what they are (of course) so if I have, say, a
window struct, I name it struct window, I usually don't bother
typedefing them.

On the other hand, a declaration like `Window *w' is shorter (and imho
more readable) than `struct window *w'.

But now I can't use the window as variable name
(yes, I know I *can*, but I won't, I don't want to be confused
by using the same name for both struct and variable).

At least I find `Window *window' to be less confusing than `struct
window *window'.

I can use the name w for the variable in functions that do
operations on the window, that works,

Sounds sensible to me. The only exception is one-letter names like `l',
`I', `o' and `O'.

but if I add a struct
widget, I don't want that to also have the name w in function.

In this case I would spell out the names:

void foo(Window* window, Widget *widget);

or maybe use

void foo(Window* win, Widget *wid);

I want to be consistent in my variable naming in the function
arguments,

Absolute consistency is not necessarily a good thing. Note that the
names you choose for exported features are more important, since these
names will be used by clients.

and it would be confusing to use w for both windows
and widgets.

If they don't occur in the same function I see no problem.

Maybe prefixing or postfixing the structname, I've seen
names ending with _t for type, but that violates the standard,
right? Maybe _s is a good choice?

Personally, I don't like Hungarian notation.


August

 

[Herbert Rosenau]

Hi
I have problems giving my structs good names, I usually name
them after what they are (of course) so if I have, say, a
window struct, I name it struct window, I usually don't bother
typedefing them. But now I can't use the window as variable name
(yes, I know I *can*, but I won't, I don't want to be confused
by using the same name for both struct and variable).

When you defines a struct you are defining a kind of template. When
you defines a variable you defines a specific object.

struct car is a normative car, struct house is a normative house.

struct car ford is a specific car, struct house my_home is a specific
house.

So find a generic name for the struct and a more specific name for the
objects.

For typedef I use all uppercase to show up that it is a type. Anyway I
don't use hungarian notation consistent but first letter P (type) or p
(object) flags pointers to distinguish them from type/variable of same
name.

So I have

ADDRESS address;
PADDRESS paddress;

CUSTOMER customer;
PCUSTOMER pcustomer;

pCustomer createCustomer(PCUSTOMER pcustomer, /* list of customers */
PADDRESS paddress, /* NULL or known
address */
PPHONE pphone, /* NULL or customers
phone */
.....);
--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Ian Collins]

For typedef I use all uppercase to show up that it is a type. Anyway I
don't use hungarian notation consistent but first letter P (type) or p
(object) flags pointers to distinguish them from type/variable of same
name.

The most common use of all upper case is for macros, so a lot (maybe the
majority?) of C programmer would find this style hard to read.

 

[lovecreatesbeauty]

I have problems giving my structs good names, I usually name
them after what they are (of course) so if I have, say, a
window struct, I name it struct window, I usually don't bother
typedefing them. But now I can't use the window as variable name
(yes, I know I *can*, but I won't, I don't want to be confused
by using the same name for both struct and variable).

Yes, this feature seems like a bug and should have been removed from
it.

struct window{};
struct window window;

I can use the name w for the variable in functions that do
operations on the window, that works,

One static type can generate thousands of objects. Keep the unique name
for that type, the derived objects can have names such as w1, w2, w3,
w999, w1001. Similar names are used in this one in the standard thing:

char *strcpy(char * restrict s1, const char * restrict s2);

but if I add a struct
widget, I don't want that to also have the name w in function.
I want to be consistent in my variable naming in the function
arguments, and it would be confusing to use w for both windows
and widgets. Of course I can just use wt or anything as a
variable name, but I thought maybe I should change the
name of the struct so that I can freely choose the names of
the variables.
Maybe prefixing or postfixing the structname, I've seen
names ending with _t for type, but that violates the standard,
right? Maybe _s is a good choice?

It is not natural to add prefixes or postfixes.

 

[Keith Thompson]

Yes, this feature seems like a bug and should have been removed from
it.

If you mean it should have been removed from the language, I disagree.
Structure tags are in their own namespace. Given a declaration like
struct window { ... };
the identifier "window" refers to the type if and only if it
immediately follows the "struct" keyword, so there's no ambiguity.

struct window{};
struct window window;


One static type can generate thousands of objects. Keep the unique name
for that type, the derived objects can have names such as w1, w2, w3,
w999, w1001. Similar names are used in this one in the standard thing:

char *strcpy(char * restrict s1, const char * restrict s2);

Sure, but ideally the names of variables reflect what they're actually
used for. Generic names like w1, w2 and so forth can sometimes make
sense as arguments to functions (though IMHO "target" and "source"
would have been better names for the arguments to strcpy()). But
unles you're only going to have a single object of a given type,
typically the purpose of the object will suggest a name.

[...]

It is not natural to add prefixes or postfixes.

That's an overly general statement.

 

[goose]

On the other hand, a declaration like `Window *w' is shorter (and imho
more readable) than `struct window *w'.

It may be shorter, although not IMHO more readable. Leaving
off the typedef ensures that throughout the code whenever
that data is used/referenced/etc the context clearly
identifies it as a struct.

Once you typedef it[1], the reader has no idea that it is
a struct.

e.g.

struct one {
...
};

typedef struct {
...
} two;

....
struct one first_var; /* clearly first_var is a struct */
two second_var; /* no clue to the reader what second_var is */

It helps elsewhere as well.

void foo (struct one first) /* arg is definately a struct */
{
...
}
void bar (two second) /* not clear what the arg is */
{
...
}

I generally use typedefing for creating /new/ datatypes[2]
although I'd be interested in knowing what the regs here
generally prefer, and why.

[1] Which is why C++ annoys me so, with automatically
typedef'ing all my structs!

[2] Like this:
typedef struct opaque_t *opaque_t;

goose,

 

[goose]

The most common use of all upper case is for macros, so a lot (maybe the
majority?) of C programmer would find this style hard to read.

I've seen at least one vendor of hardware supply an
OS which had an interface with all the types in UPPERCASE;
drove me nuts

goose,

 

[Richard]

On the other hand, a declaration like `Window *w' is shorter (and imho
more readable) than `struct window *w'.

It may be shorter, although not IMHO more readable. Leaving
off the typedef ensures that throughout the code whenever
that data is used/referenced/etc the context clearly
identifies it as a struct.

Once you typedef it[1], the reader has no idea that it is
a struct.

Agreed and a fairly robust reason not to use it unless its to wrap
difficult to understand types/function declarations. Unless you have a
reason to hide the natural types, keep them - its better in the long run
to see the types you are dealing with as opposed to renaming the world
and their mother in order to save typing "struct" at declaration
time. Highly subjective of course.

 

[Herbert Rosenau]

The most common use of all upper case is for macros,

That's true.Have you ever seen a macro like
ADDRESS home;
PADDRESS pneighbour;

As my OS uses this form of #typedef since the old days where DOS was
starting to get outdated and windows was not even born other than a
graphical shell sitting in front of it I learned to use the same
style.

so a lot (maybe the

majority?) of C programmer would find this style hard to read.

Not really. Or is Windows only known to a handful peoples? It does
exactly the same.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Herbert Rosenau]

One static type can generate thousands of objects. Keep the unique name
for that type, the derived objects can have names such as w1, w2, w3,
w999, w1001. Similar names are used in this one in the standard thing:

Totally unmaintable. When you were my employee you gets fired on that.

As a programmer you would have learned to give types, macros,
functions and variable names speaking by themself.


--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Richard]

The most common use of all upper case is for macros, so a lot (maybe the
majority?) of C programmer would find this style hard to read.

Most APIs I've used for windows/OS2 windowing environments tended to use
a lot of upper case for data typing and windows messaging. The worst
ever were oracle bindings afaicr.

 

[Herbert Rosenau]

It may be shorter, although not IMHO more readable. Leaving
off the typedef ensures that throughout the code whenever
that data is used/referenced/etc the context clearly
identifies it as a struct.

struct one is a completely useless name. It doesn't help to know that
one is a struct.
Give the damn thing a selfdocumenting name and you would even HOUSE
identify as a struct describing a house or CAR a struct describing a
car without the magic leading struct.

Once you typedef it[1], the reader has no idea that it is
a struct.

e.g.

struct one {
...
};

typedef struct {
...
} two;

...
struct one first_var; /* clearly first_var is a struct */

So what stands struct one for. No reader will have an idea -> useless.

two second_var; /* no clue to the reader what second_var is */

Not more, not less as struct one. Useless because the name of the
thing says nothing.

It helps elsewhere as well.

void foo (struct one first) /* arg is definately a struct */
{
...
}
void bar (two second) /* not clear what the arg is */
{
...
}

The arg is definitely what its type says. Give the self defined types
names, show up that it IS a type by using all uppercase and give the
objects themself even names documenting what they are.

I generally use typedefing for creating /new/ datatypes[2]
although I'd be interested in knowing what the regs here
generally prefer, and why.

You can't create new data types in C. You can easy create aliases for
known datatypes. So ADDRESS is a struct containing an address. Easy to
understund.

[1] Which is why C++ annoys me so, with automatically
typedef'ing all my structs!

[2] Like this:
typedef struct opaque_t *opaque_t;

goose,

Don't use meaningless typenames. Don't use meaningless names in
general.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Keith Thompson]

struct one is a completely useless name. It doesn't help to know that
one is a struct.
Give the damn thing a selfdocumenting name and you would even HOUSE
identify as a struct describing a house or CAR a struct describing a
car without the magic leading struct.

Or you can use "struct house" or "struct car". Using descriptive
names is independent of the question of whether or not to use typedefs
for structures.

The names 'struct one" and "two" were obviously just examples, just
like the function names "foo" and "bar".

[...]

The arg is definitely what its type says. Give the self defined types
names, show up that it IS a type by using all uppercase and give the
objects themself even names documenting what they are.

It's traditional to use all-caps for macros and possibly for
enumeration constants. Most programmers don't use all-caps for type
names. Not that there's anything wrong with doing so, but if you're
trying to make it obvious that it's a type name, it might not work for
all readers. (On the other hand, preceding an identifer with the
keyword "struct" does make it obvious.)

I generally use typedefing for creating /new/ datatypes[2]
although I'd be interested in knowing what the regs here
generally prefer, and why.

You can't create new data types in C. You can easy create aliases for
known datatypes. So ADDRESS is a struct containing an address. Easy to
understund.

Yes, you can create new data types in C; a struct definition is one of
several ways to do so.

[...]

Don't use meaningless typenames. Don't use meaningless names in
general.

Agreed.

 

[goose]

struct one is a completely useless name. It doesn't help to know that
one is a struct.
Give the damn thing a selfdocumenting name and you would even HOUSE
identify as a struct describing a house or CAR a struct describing a
car without the magic leading struct.

No you idiot; they could be describing something else;
HOUSE on its own might be describing a struct, or perhaps
an enum, or maybe another typedef ...

<snipped clueless rant>

goose,

 

[Herbert Rosenau]

Most APIs I've used for windows/OS2 windowing environments tended to use
a lot of upper case for data typing

No, you means typedefs.

and windows messaging.

You means macros.

And mixed case makes something more readable.


The worst

ever were oracle bindings afaicr.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!