macro conventions

[Bill Cunningham]

In defining macros it is of course proper style to use all caps for
example:

#define AVG 14

There are other conventions too. In trying to learn what is the
diference in having one underscore and two underscores in front of or behine
a macro? For example:

#define __FILE__

Two underscores if front of and behind the define. And here:

#define _GNU_SOURCE

One underscore in front and no underscores at the end. I hope this is clear.
I want to be sure of these things.

Bill

 

[Shao Miller]

In defining macros it is of course proper style to use all caps for
example:

#define AVG 14

There are other conventions too. In trying to learn what is the
diference in having one underscore and two underscores in front of or behine
a macro? For example:

#define __FILE__

Two underscores if front of and behind the define. And here:

#define _GNU_SOURCE

One underscore in front and no underscores at the end. I hope this is clear.
I want to be sure of these things.

From the C99 draft with filename 'n1265.pdf' and its section 6.10.8,
point 4, we find that "Any other predefined macro names shall begin with
a leading underscore followed by an uppercase letter or a second
underscore."

In section 7.1.3, point 1, we find that "All identifiers that begin with
an underscore and either an uppercase letter or another underscore are
always reserved for any use" as well as "All identifiers that begin with
an underscore are always reserved for use as identifiers with file scope
in both the ordinary and tag name spaces."

I don't think there's anything special about underscores beyond that,
but I could be mistaken.

The two following underscores you noted in '__FILE__' are not special,
as far as I know; they're merely part of that standard macro name.

 

[ralph]

In defining macros it is of course proper style to use all caps for
example:

#define AVG 14

There are other conventions too. In trying to learn what is the
diference in having one underscore and two underscores in front of or behine
a macro? For example:

#define __FILE__

Two underscores if front of and behind the define. And here:

#define _GNU_SOURCE

One underscore in front and no underscores at the end. I hope this is clear.
I want to be sure of these things.

Bill

In general:

The use of two underscores ('__') followed by an uppercase letter in
identifiers is reserved for the compiler's internal implementation.

The use of one Underscore ('_') followed by either an upper or lower
case letter in identifiers are reserved for the vendor's
implementation or extensions to the language.

Traditionally macros are all caps to make them more visible within
code made up of mostly lower case characters. There are several nasty
side-effects and nuances associated with macros that makes anything
you can do to make them stand-out useful.

The actual 'rules' and conventions are more complicated and others
will be along shortly to quote chapter and verse. However, in order to
avoid collisions, best practice is simply never create a macro with an
underscore for your own use and use always use uppercase.

-ralph

 

[Keith Thompson]

From the C99 draft with filename 'n1265.pdf' and its section 6.10.8,
point 4, we find that "Any other predefined macro names shall begin with
a leading underscore followed by an uppercase letter or a second
underscore."

[...]

You mean n1256.pdf, not n1265.pdf.

It's available at <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>.

 

[Bill Cunningham]

You mean n1256.pdf, not n1265.pdf.

It's available at
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>.

All right got it. Thanks Keith.

Bill

 

[Bill Cunningham]

The actual 'rules' and conventions are more complicated and others
will be along shortly to quote chapter and verse. However, in order to
avoid collisions, best practice is simply never create a macro with an
underscore for your own use and use always use uppercase.
Thanks.

Bill


-ralph

 

[Bill Cunningham]

The actual 'rules' and conventions are more complicated and others
will be along shortly to quote chapter and verse. However, in order to
avoid collisions, best practice is simply never create a macro with an
underscore for your own use and use always use uppercase.

-ralph

Isn't there also some conventions used in kernel source code. The Linux
kernel source that I have looked at (and its been awhile) has some pretty
different uses in declaring macro names too. But if I am understanding you
and others in this thread for anything I will be dealing with just the all
caps will do.

Bill

 

[Angel]

Isn't there also some conventions used in kernel source code. The Linux
kernel source that I have looked at (and its been awhile) has some pretty
different uses in declaring macro names too. But if I am understanding you
and others in this thread for anything I will be dealing with just the all
caps will do.

Kernel programming is very different from normal application
programming on many levels.

For example, you cannot use any of the standard libraries, so
you cannot use the usual printf() or malloc(). (The kernel source does
provide kprintf() and kalloc() though, but they don't work quite the
same.)

And yes, the kernel also has its own macro conventions.

 

[Keith Thompson]

The actual 'rules' and conventions are more complicated and others
will be along shortly to quote chapter and verse. However, in order to
avoid collisions, best practice is simply never create a macro with an
underscore for your own use and use always use uppercase.

TO be clear, it's leading underscores that should be avoided. FOO_BAR,
for example, is perfectly ok. Trailing underscores are also ok, though
I wouldn't use them without a good reason.

 

[Malcolm McLean]

TO be clear, it's leading underscores that should be avoided.  FOO_BAR,
for example, is perfectly ok.  Trailing underscores are also ok, though
I wouldn't use them without a good reason.

One problem with underscores is that they are not pronounced. So it
can be hard to remember whether it's FOO_BAR or FOOBAR. Also,
experience with websites has shown that people prefer words
runtogetherratherthan separated_out_by_underscores, if spaces aren't
an option.

 

[Ian Collins]

One problem with underscores is that they are not pronounced. So it
can be hard to remember whether it's FOO_BAR or FOOBAR.

They are pounced as a space or pause, FOO_BAR is pronounced as FOO BAR,
not FOOBAR.

Also,
experience with websites has shown that people prefer words
runtogetherratherthan separated_out_by_underscores, if spaces aren't
an option.

Citation? I could understand runTogetherRatherThan.

 

[osmium]

On 05/16/11 03:29 AM, Malcolm McLean wrote:

[E]xperience with websites has shown that people prefer words
runtogetherratherthan separated_out_by_underscores, if spaces aren't
an option.

Citation? I could understand runTogetherRatherThan.

I share your skepticism, but a citation wouldn't really help, would it?
This is subjective, social sciences kind of stuff. And this is Usenet.
sometiomespeoplesimplymakethingsup.

 

[Phil Carmody]

Kernel programming is very different from normal application
programming on many levels.

Bill Cunningham is very different from normal usenet posters on many levels.

Just killfile him, his indistinguishability from a troll has reached epsilon.

Please.

Phil

 

[ralph]

TO be clear, it's leading underscores that should be avoided. FOO_BAR,
for example, is perfectly ok. Trailing underscores are also ok, though
I wouldn't use them without a good reason.

Thanks for that catch. I did make it sound like underscores should be
avoided throughout an identifier, when they are in fact OK.

It should also be amplified that double underscores "_ _" are reserved
even within or trailing an identifier

FOO_BAR is OK, FOO__BAR or FOOBAR__ is not.

Luckily most collisions are grievous enough to become quickly
identified during development. Real trouble often comes about, not
from using underscores per se, but from using certain keywords,
letters, or library tags as prefixes. For example, many years back I
remember a team getting tangled up with macros beginning with "E_",
"SIG_", "XL_", and "H_".

The problem in that case was not the few hours lost to development to
go back and clean it up. It was the endless ugliness that came about
because some pointed-hair boss decided that to avoid all future
collisions, all macros would be defined as ...

ABC_Co_FOO_BAR,
ABC_Co_Inventory_FOO_BAR,
ABC_Co_Errors_FOO_BAR,
ABC_Co_HeaderFile_FOO_BAR
...

Moral of the story: If you are working on a team and have a collision
- fix it AND keep your mouth shut. <bg>

-ralph

 

[Ike Naar]

Just killfile him, his indistinguishability from a troll has reached epsilon.

Killfile someone who doesn't appear to be a troll?

 

[Ben Bacarisse]

Thanks for that catch. I did make it sound like underscores should be
avoided throughout an identifier, when they are in fact OK.

It should also be amplified that double underscores "_ _" are reserved
even within or trailing an identifier

FOO_BAR is OK, FOO__BAR or FOOBAR__ is not.

What's your source?

<snip>

 

[David Resnick]

[...]
The actual 'rules' and conventions are more complicated and others
will be along shortly to quote chapter and verse. However, in order to
avoid collisions, best practice is simply never create a macro with an
underscore for your own use and use always use uppercase.
TO be clear, it's leading underscores that should be avoided.  FOO_BAR,
for example, is perfectly ok.  Trailing underscores are also ok, though
I wouldn't use them without a good reason.

Thanks for that catch. I did make it sound like underscores should be
avoided throughout an identifier, when they are in fact OK.

It should also be amplified that double underscores "_ _" are reserved
even within or trailing an identifier

     FOO_BAR is OK, FOO__BAR or FOOBAR__ is not.

What's your source?

<snip>

I'd guess his source is the C++ standard, where any identifier with __
is reserved. Yes, not generally relevant here, unless you want go
keep your C header compatible with C++ for some reason.

-David

 

[Keith Thompson]

[...]

TO be clear, it's leading underscores that should be avoided. FOO_BAR,
for example, is perfectly ok. Trailing underscores are also ok, though
I wouldn't use them without a good reason.

Thanks for that catch. I did make it sound like underscores should be
avoided throughout an identifier, when they are in fact OK.

It should also be amplified that double underscores "_ _" are reserved
even within or trailing an identifier

FOO_BAR is OK, FOO__BAR or FOOBAR__ is not.

[...]

No, they aren't. I think C++ reserves idenifiers with double
underscores (so they can be used for name mangling, if I recall
correctly), but C doesn't.

Still, it certainly couldn't hurt to avoid double underscores in
C code.

 

[Phil Carmody]

Killfile someone who doesn't appear to be a troll?

What's weird about that? I think my killfile is about 75% idiots and 50% trolls.
His posts are noise, the replies to them are mostly noise.

Phil

 

[Ben Bacarisse]

I'd guess his source is the C++ standard, where any identifier with __
is reserved. Yes, not generally relevant here, unless you want go
keep your C header compatible with C++ for some reason.

I'd say it is relevant here, but it would have helped to know it was
"just in case" advice rather than the usual meaning of "reserved".