By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,474 Members | 939 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,474 IT Pros & Developers. It's quick & easy.

New coding standards: use underscores, hyphens or mixed case in command (and identifier) names

P: n/a

Before I embark on a new long-term project I'd appreciate your advice on how to split up
long names. I would like to keep the standards for command names the same as that for
variable names. Looking at the examples below, which ones seem better?

Straight names
echoclient
lastcharoffset
helloworld

Internal underscores
echo_client
last_char_offset
hello_world

I could also use embedded hyphens as my minus sign must be surrounded by whitespace
(please suspend disbelief while looking at these. I know they will look unfamiliar!)
echo-client
last-char-offset
hello-world

Mixed case
EchoClient
LastCharOffset
HelloWorld

Initial lower case then mixed
echoClient
lastCharOffset
helloWorld

In some ways I like the mixed case versions using an inital capital, especially as I may
want to prefix some names with a code for an abstract data type, which, when present,
could begin with a lower case. Is this getting too Microsoft-ish? Is it getting to
Hungarian? Is Hungarian bad when used with abstract data types rather than inbuilt ones?

Advice on which is or is not thought to be acceptable would be much appreciated. Please
bear in mind that I intend these names for commands/instructions as well as variables and
types. Constants would be in all caps.

--
Thanks,
James
Nov 14 '05 #1
Share this Question
Share on Google+
46 Replies


P: n/a
James Harris a formulé la demande :
Before I embark on a new long-term project I'd appreciate your advice on how
to split up long names. I would like to keep the standards for command names
the same as that for
There is not standard about that. It may have company rules you are
supposed to follow (or create)
variable names. Looking at the examples below, which ones seem better?
What do you mean by 'command name' ? No such a thing like a 'command'
in C.
Straight names
echoclient
lastcharoffset
helloworld
Unreadable to me (and others, I guess).
Internal underscores
echo_client
last_char_offset
hello_world
Ok
I could also use embedded hyphens as my minus sign must be surrounded by
whitespace
No such a thing in C.
Mixed case
EchoClient
LastCharOffset
HelloWorld
Ok
Initial lower case then mixed
echoClient
lastCharOffset
helloWorld
Sounds ugly to me, but who cares...
In some ways I like the mixed case versions using an inital capital,
especially as I may want to prefix some names with a code for an abstract
data type, which, when present, could begin with a lower case. Is this
getting too Microsoft-ish? Is it getting to Hungarian? Is Hungarian bad when
used with abstract data types rather than inbuilt ones?


Original Hugarian is good,

a_xxx : array
p_yyy : pointer
s_zzz : string
etc.
but Hungarian ŕ-la-Microsoft (typed) is evil and hard to read and
maintain.

--
Ceci est une signature automatique de MesNews.
Site : http://mesnews.no-ip.com

Nov 14 '05 #2

P: n/a
James Harris <no.email.please> scribbled the following:
Before I embark on a new long-term project I'd appreciate your advice on how to split up
long names. I would like to keep the standards for command names the same as that for
variable names. Looking at the examples below, which ones seem better? I could also use embedded hyphens as my minus sign must be surrounded by whitespace
(please suspend disbelief while looking at these. I know they will look unfamiliar!)
echo-client
last-char-offset
hello-world


Since when was the hyphen a legal character in a C identifier?

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"How can we possibly use sex to get what we want? Sex IS what we want."
- Dr. Frasier Crane
Nov 14 '05 #3

P: n/a
James Harris <no.email.please> wrote:
Before I embark on a new long-term project I'd appreciate your advice
on how to split up long names. I would like to keep the standards for
command names the same as that for variable names. Looking at the
examples below, which ones seem better?
Please fix your line lenghts to something of around 70 (I reformatted
the text to make things readable).
Straight names
echoclient
lastcharoffset
helloworld Internal underscores
echo_client
last_char_offset
hello_world
I would much prefer the second since it's way easier to read and
typos are easier to recognize. Just compare

lastcharoffset <-> last_char_offset
lastcharofset <-> last_char_of_set

and it should become clear immediately why I feel that way.
I could also use embedded hyphens as my minus sign must be surrounded
by whitespace (please suspend disbelief while looking at these. I know
they will look unfamiliar!)
echo-client
last-char-offset
hello-world
Huh? Unless you do some automatic conversion of the source code before
you pass it to the compiler that won't do what you expect...
Mixed case
EchoClient
LastCharOffset
HelloWorld Initial lower case then mixed
echoClient
lastCharOffset
helloWorld In some ways I like the mixed case versions using an inital capital,
Well, I still would prefer the version with underscores since they
seem still easier to read (you immediately see the subdivision in
words because we're trained to expect spaces between words) but
having the upper case at the start of words gives you at least a lot
more visual clues then without. What becomes a problem with the
use of upper case characters is when you want to code some extra
meaning into the use of upper/lower case, e.g. have global variables
always start with an upper case character but everything else in
lower case and upper case for all word starts for typedef'ed stuff
like in

Var_array <- a global variable
Var_Type <- a type with a typedef somewhere in the headers
especially as I may want to prefix some names with a code for an
abstract data type, which, when present, could begin with a lower
case. Is this getting too Microsoft-ish? Is it getting to Hungarian?
Is Hungarian bad when used with abstract data types rather than
inbuilt ones?
Well, lots of people loath Hungarian notation (and I am admittedly
one of them) because

a) all that stuff at the start makes it harder to read since you
always have to scan for the real variable name, especially when
used without an intervening underscore and you end up with names
like 'rgbsyHash' or 'rgwDic' (as taken directly from an article

http://cm-solutions.com/cms/technica...convention.htm

by its inventor Simonyi, it shows rather nicely why not to use it,
the example code mostly looks to me as if it had been rot13'ed),

b) if you're that far away from the definition of a variable that
it gets tedious to look it up (and you can't remember it) then
your function probably has already become too long

c) or, if this is a variable that is defined somewhere else, it
should have a name that at least gives you a clue to what its
type is.
Advice on which is or is not thought to be acceptable would be much
appreciated. Please bear in mind that I intend these names for
commands/instructions as well as variables and types. Constants would
be in all caps.


I tend to write function names in lower case only - that it's a
function normally is obvious because of the parenthesis following
it.
Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de
Nov 14 '05 #4

P: n/a


James Harris wrote:
Before I embark on a new long-term project I'd appreciate your advice on how to split up
long names. I would like to keep the standards for command names the same as that for
variable names. Looking at the examples below, which ones seem better?

Straight names
echoclient
lastcharoffset
helloworld
No, you've got to separate words somehow for readability.
Internal underscores
echo_client
last_char_offset
hello_world
OK, but obviously takes one more char than mixed case.
I could also use embedded hyphens as my minus sign must be surrounded by whitespace
(please suspend disbelief while looking at these. I know they will look unfamiliar!)
echo-client
last-char-offset
hello-world
No, not legal C and worth avoiding in any language that would allow it.
Mixed case
EchoClient
LastCharOffset
HelloWorld
OK, but the assumption then is that your variables start with an
upper-case letter and, if you follow that rather than special-casing it,
then your one-char tmp counter names should be, say, "I" which looks
weird and probably invades your other naming conventions such as
reservaing all-upper-case for enum, macro, and type names.
Initial lower case then mixed
echoClient
lastCharOffset
helloWorld
I'd go with that.
In some ways I like the mixed case versions using an inital capital, especially as I may
want to prefix some names with a code for an abstract data type, which, when present,
could begin with a lower case.
So if you start with lower-case then "helloWorld" would be "xHelloWorld"
- that seems fine. You could also introduce an underscore between the
code and the rest of the word if that's important.

Is this getting too Microsoft-ish? Is it getting to Hungarian? Is Hungarian bad when used with abstract data types rather than inbuilt ones?

Advice on which is or is not thought to be acceptable would be much appreciated. Please
bear in mind that I intend these names for commands/instructions as well as variables and
types. Constants would be in all caps.
By commands/instructions, I assume you mean "functions" and the above
would be fine for those.

Ed.
--
Thanks,
James


Nov 14 '05 #5

P: n/a
In other news, Ed Morton <mo****@lsupcaemnt.com> was quoted today as
saying:
James Harris wrote: No, not legal C and worth avoiding in any language that would allow
it.
Mixed case
EchoClient
LastCharOffset
HelloWorld


OK, but the assumption then is that your variables start with an
upper-case letter and, if you follow that rather than special-casing
it, then your one-char tmp counter names should be, say, "I" which
looks weird and probably invades your other naming conventions such as
reservaing all-upper-case for enum, macro, and type names.


The answer to which might be to avoid one-char tmp counter names ;)
Initial lower case then mixed
echoClient
lastCharOffset
helloWorld


I'd go with that.


This is what I find myself using as it feels more natural than the others.

--
runtime
Nov 14 '05 #6

P: n/a

Be consistent and choose something readable.

thisisalongname() is not readable and I can't see many people would endorse
this way.

this_is_a_long_name() is fairly accepatble I feel. However at the moment I
use a style like this:
ModuleX_ThisIsALongName()

I use the uncapitalised method for local variables:

size_t line_count;

and sometimes I use an 'a' prefix for arguments, although I am not entirely
happy with this:

fn( aDest, aSrc, aLen )
{
}

It's not easy to say what is best, but I would avoid anything too
extravegant like hungarian notation, I prefer naming conventions to give
information about the semantects of an identifier rarther than it's type.
i.e. I use aParamater, rathar than saying iParamater ( meaning integer )
because then you might have to rename all your identifiers if they change
type.

Nov 14 '05 #7

P: n/a

"James Harris" <no.email.please> wrote in message


Before I embark on a new long-term project I'd appreciate your advice on
how to split up long names. I would like to keep the standards for command
names the same as that for variable names. Looking at the examples below,
which ones seem better?

You are not using C. However you should have very few variables in scope in
any structured programming language. Variables within a function can be
called anything meaningful (eg i for a nondescript counter, N for a count of
objects, x and y for co-ordinates, theta for an angle, ptr for a pointer,
ojprice for the price of orange juice etc). The few global variables you
need should be prefixed g_ and then called anything.

However you could have many hundreds of function identifiers. What I do is
name portable (in C, pure ANSI C ) functions in lowercase, whilst
platform-specific functions have Uppercase Initials.
Normally you won't have namespace clashes for your portable functions,
because you are developing them as a corpus. The name can be kept relatively
short. The exception is when you are doing many operations on a structure
(eg to get the salary of a programmer, and artist, and a manager). What you
do is prefix every function with the name of the structure you pass it, so
we have

programmer_salary()
artist_salary();
manager_salary();

You shouldn't need longer names, eg programmer_initial_salary is bad because
it rapidly gets unreadable. Try to think of a short identifier instead.

Platform-specific functions can multiply to huge numbers, particularly is
you are writing an interactive program, so initialise the first letter of
each word.

MoveMouseCursor()

etc.

The problem with both underscores and capitals is that they are not
pronounced. Most people remember words by sound, because that is the primary
way we use language. Thus mouse_wheel and mousewheel rapidly become
confused. So it is important to stick to some consistent convention.
Nov 14 '05 #8

P: n/a
hungarian notation might be somthing you can look into but I dont'
think you will read all that. It really is pointless(IMO) I use
the opengl way of declaring functions ex:

glTexSubImage();

although I have programmed in GTK and they use the _ method

gtk_radio_button_new_with_label_from_widget

the latter method really starts to hurt your wrist if you are writing
a long program and use the correct typing method(Too must reaching +
it throws off the rythm of typing(slows you down)). I would recommend
the former Faster and one less keystroke
Nov 14 '05 #9

P: n/a
"James Harris" <no.email.please> wrote in message
news:40**********************@news.zen.co.uk...

Before I embark on a new long-term project I'd appreciate your advice on
how to split up long names. I would like to keep the standards for
command names the same as that for variable names. Looking at the
examples below, which ones seem better?
Which style you use is a matter of personal preference, as long as you pick
a single style and stick with it.
Initial lower case then mixed
echoClient
lastCharOffset
helloWorld


This is what I use, but the initial-caps style and underscored (not
hyphenated) style are both common as well.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

Nov 14 '05 #10

P: n/a
kal
"James Harris" <no.email.please> wrote in message news:<40**********************@news.zen.co.uk>...

Are you "James S Harris"?
Nov 14 '05 #11

P: n/a

On Tue, 20 Jul 2004, kal wrote:

"James Harris" <no.email.please> wrote...

Are you "James S Harris"?


If he is, he's using a different (munged) email, no middle initial,
and a much, much saner brain. I doubt there's any relation. :)
(James: JSH is a well-known sci.math kook, in case you haven't
already heard it a thousand times before. ;)

-Arthur
Nov 14 '05 #12

P: n/a
In <a5**************************@posting.google.com > k_*****@yahoo.com (kal) writes:
"James Harris" <no.email.please> wrote in message news:<40**********************@news.zen.co.uk>...

Are you "James S Harris"?


What was your C language question?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #13

P: n/a
Dan Pop wrote:
kal writes:
Are you "James S Harris"?


What was your C language question?


well then, what was YOUR C language question?
Nov 14 '05 #14

P: n/a
In <20040720182631.6de53ef8@localhost> Sam Halliday <em***@example.com> writes:
Dan Pop wrote:
kal writes:
>Are you "James S Harris"?


What was your C language question?


well then, what was YOUR C language question?


Topicality issues are, *always*, topical. So, my question was topical
even without being about C.

And your point was?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #15

P: n/a
Emmanuel Delahaye <em***@YOURBRAnoos.fr> wrote in
news:mn***********************@YOURBRAnoos.fr:
Initial lower case then mixed
echoClient
lastCharOffset
helloWorld


Sounds ugly to me, but who cares...


I do. I'd use EchoClient to be a type and echoClient to be an "object".
E.g. EchoClient echoClient; or Foo foo; Leading cap. followed by lower
case always means a type (not the standard types mind you) in my little
world.

My simple 3 rules:

1) manifest constant or enum:

#define FOO_ONE 1
enum Foo { FOO_ONE = 1 };

2) Types or tags:

typedef enum Foo { ... } Foo;
typedef struct Bar { ... } Bar;

3) Vars. and functions:

int someVariableOne;
char arrayOfChars[NUM_CHARS];
float getFloatFromBar(Bar bar);

--
- Mark ->
--
Nov 14 '05 #16

P: n/a
kal
Da*****@cern.ch (Dan Pop) wrote in message news:<cd**********@sunnews.cern.ch>...
Are you "James S Harris"?


What was your C language question?


Don't be so hasty. I am thinking, I am THINKING...

At present I only have C anxiety.

I enjoyed hanging out at sci.math (wonderful folks there,
they are infinitely patient while explaining things to you)
till the discussion about FLT got way too "technical" for
me and my antidiluvian computer.

Just was wondering if I should pack my bags again.
Nov 14 '05 #17

P: n/a

"kal" <k_*****@yahoo.com> wrote in message
news:a5**************************@posting.google.c om...
"James Harris" <no.email.please> wrote in message news:<40**********************@news.zen.co.uk>...
Are you "James S Harris"?


No, not that one!
Nov 14 '05 #18

P: n/a

"Emmanuel Delahaye" <em***@YOURBRAnoos.fr> wrote in message
news:mn***********************@YOURBRAnoos.fr...
What do you mean by 'command name' ? No such a thing like a 'command'
in C.


I was thinking of executable file names, mainly. Hence the hyphenated
versions. I was thinking of the user having to type the command to run the
program so,

helloworld
hello-world
hello_world
helloWorld
HelloWorld

I know a file name format is not C per se but it is often used to run a C
program - my only excuse for including it in this NG.

I must admit the hyphenated version is growing on me because it doesn't
require the user to think about or change case, separates the words of the
command (if it has more than one) and doesn't require the user to use the
underscore character. Hmm....... Is a hyphen so bad....?
--
James
Nov 14 '05 #19

P: n/a

<Je***********@physik.fu-berlin.de> wrote in message
news:2l************@uni-berlin.de...

Well, lots of people loath Hungarian notation (and I am admittedly
one of them) because

a) all that stuff at the start makes it harder to read since you
always have to scan for the real variable name, especially when
used without an intervening underscore and you end up with names
like 'rgbsyHash' or 'rgwDic' (as taken directly from an article

http://cm-solutions.com/cms/technica...convention.htm
by its inventor Simonyi, it shows rather nicely why not to use it,
the example code mostly looks to me as if it had been rot13'ed),


Ow! I see what you mean. That's not what I was thinking of. I had seen
Hungarian as szVaviable as a string terminated by a zero. I've never used
the codes so this may not be right but something like iVariable being an
integer. (Memories of Fortran....?)

I can see a benefit to having the broad type of a variable clearly
visible. - e.g. is it a number or a string? I don't know how far I would
want this to go, though. Any suggestions?

--
Thanks,
James
Nov 14 '05 #20

P: n/a
James Harris vient de nous annoncer :
What do you mean by 'command name' ? No such a thing like a 'command'
in C.
I was thinking of executable file names, mainly.


Hence, it's hardly a C-question.
Hence the hyphenated
versions. I was thinking of the user having to type the command to run the
program so,

helloworld
hello-world
hello_world
helloWorld
HelloWorld

I know a file name format is not C per se but it is often used to run a C
program - my only excuse for including it in this NG.


There is no such a thing like a C-program. One one hand, you have
C-sources, and on the other hand, you have executables. Who knows/cares
about the original language it was written in ?

--
Emmanuel

Nov 14 '05 #21

P: n/a
"James Harris" <no.email.please> wrote in message news:<40**********************@news.zen.co.uk>...
Before I embark on a new long-term project I'd appreciate your advice on how to split up
long names. I would like to keep the standards for command names the same as that for
variable names. Looking at the examples below, which ones seem better?


Everyone has his own style, so everyone has his own opinions. Here's
my particular style of naming:

* Use internal underscores to separate words.
* Types are in uppercase and end with _T .
* Enumeration values and macro names are in uppercase.
* Synonyms for types generated via typedef have the same name as the
struct or union tag that is being synonymed; e.g.

typedef struct TAG_T {
/* ... */
} TAG_T;

* Headers should include header guards to prevent multiple inclusion;
e.g.

#ifndef FILE_H
#define FILE_H
/* rest of header goes here */
#endif

The header guard has the same name as the filename, but in all
uppercase and all punctuation turned into underscores. It ends with _H
..

* Variable names are in lowercase, and each declared variable should
be in its own declaration.
* Function names should start with either a verb or a common slug
followed by a verb (e.g. DS_create, DS_destroy). They should be in
lowercase except that the slug should be in uppercase if it is there.
Cool verbs to use include "copy", "create" (bring something into
existence), "destroy" (the opposite of "create"), "get", "set", and
"transmogrify". But whatever you use, the action must be clear enough
for a ten-year-old.
* Function names that indicate a Boolean response should return int; a
nonzero value (preferably 1) indicates true and 0 indicates false. The
function name should not contain a negative word such as "not",
"non-", "never", or something similar. The phrase "is_" is a perfect
starter for a function, but the underscore must be there because "is"
followed by a non-underscore is reserved.

* Use K&R style braces, four-character indents, and no tabs.
* Lines should have no more than 78 characters.
* The switch statement should have a default case.

If there's anything I've left out, add it. I'm not going to act as the
code police. Incidental flaws can be covered with the "indent"
program, available wherever GNU products are downloaded from.

Gregory Pietsch
Nov 14 '05 #22

P: n/a

On Tue, 20 Jul 2004, Gregory Pietsch wrote:

Everyone has his own style, so everyone has his own opinions.
Yes indeed. Here's some of mine. :)
* Types are in uppercase and end with _T .
This /could/ get confusing, if you also use more than the average
quantity of macros. I prefer 'CamelCase' for OO-style typedef'ed
struct types, and '[struct|union|enum] plainoldc' for the rest; this
avoids confusion completely. Your '_T' suffix is a pretty good way
to avoid confusion with macros, too, though.

* Synonyms for types generated via typedef have the same name as the
struct or union tag that is being synonymed; e.g.

typedef struct TAG_T {
/* ... */
} TAG_T;
Better style (IMO, but note that I /am/ claiming this is objectively
better) is to write the typedef first: replace

typedef struct TAG_T {
FOO_T data;
struct TAG_T *next;
} TAG_T;

with

typedef struct TAG_T TAG_T;
struct TAG_T {
FOO_T data;
TAG_T *next;
}

Slightly more typing, but you get the benefit of being able to
use the typedef-name 'TAG_T' inside the structure definition
itself, just the way client code will get to use it.

* Headers should include header guards to prevent multiple inclusion;
e.g.

#ifndef FILE_H
#define FILE_H
/* rest of header goes here */
#endif

The header guard has the same name as the filename, but in all
uppercase and all punctuation turned into underscores. It ends with _H
Header guards are good, but again IMO it is better to replace
'FILE_H' with 'H_FILE'. This removes a pedantic objection to

#define ELEPHANT_H /* Undefined behavior, name "E..." reserved! */

and means you don't have to come up with a special-case naming
convention in that one circumstance.

* Use K&R style braces, four-character indents, and no tabs.
* Lines should have no more than 78 characters.


Hear hear!

-Arthur
Nov 14 '05 #23

P: n/a
In <a5*************************@posting.google.com> k_*****@yahoo.com (kal) writes:
Da*****@cern.ch (Dan Pop) wrote in message news:<cd**********@sunnews.cern.ch>...
>Are you "James S Harris"?


What was your C language question?


Don't be so hasty. I am thinking, I am THINKING...


If you really were, you'd have easily realised that your question
belonged to private email, rather than gratuitously abusing the newsgroup.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #24

P: n/a
James Harris wrote:
Before I embark on a new long-term project I'd appreciate your advice on how to split up
long names. I would like to keep the standards for command names the same as that for
variable names. Looking at the examples below, which ones seem better?

Straight names
echoclient
lastcharoffset
helloworld

Internal underscores
echo_client
last_char_offset
hello_world

I could also use embedded hyphens as my minus sign must be surrounded by whitespace
(please suspend disbelief while looking at these. I know they will look unfamiliar!)
echo-client
last-char-offset
hello-world

Mixed case
EchoClient
LastCharOffset
HelloWorld

Initial lower case then mixed
echoClient
lastCharOffset
helloWorld

In some ways I like the mixed case versions using an inital capital, especially as I may
want to prefix some names with a code for an abstract data type, which, when present,
could begin with a lower case. Is this getting too Microsoft-ish? Is it getting to
Hungarian? Is Hungarian bad when used with abstract data types rather than inbuilt ones? IMHO, Hungarian is *always* bad: it lies.
Advice on which is or is not thought to be acceptable would be much appreciated. Please
bear in mind that I intend these names for commands/instructions as well as variables and
types. Constants would be in all caps.

I'd go for the words_separated_by_underscores. Don't "encode" types in
your identifier names - just functionality: functionality doesn't lie
(and you'll be far more inclined to change the name of a function when
its functionality changes than when its return type changes).

There's no reason to make constants all-caps, by the way: why would you
want to do that?

rlc
Nov 14 '05 #25

P: n/a
In <2m************@uni-berlin.de> Ronald Landheer-Cieslak <ro****@landheer.com> writes:
There's no reason to make constants all-caps, by the way: why would you
want to do that?


To make it obvious that they are constants and, therefore, usable in
constant expressions. As an additional bonus, the programmers would be
less tempted to change their values ;-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #26

P: n/a
Dan Pop wrote:
kal writes:
Dan Pop wrote:
>Are you "James S Harris"?
What was your C language question?

Don't be so hasty. I am thinking, I am THINKING...

If you really were, you'd have easily realised that your question
belonged to private email, rather than gratuitously abusing the newsgroup.


hes joking (some "the other" James S Harris thing).

additionally, if you looked at the original poster you would see he has "James
Harris" <no.email.please>, therefore private correspondence is out of the
question.
Nov 14 '05 #27

P: n/a
In <20040721161451.564881ea@noss> Sam Halliday <em***@example.com> writes:
Dan Pop wrote:
kal writes:
>Dan Pop wrote:
>> >Are you "James S Harris"?
>> What was your C language question?
>Don't be so hasty. I am thinking, I am THINKING... If you really were, you'd have easily realised that your question
belonged to private email, rather than gratuitously abusing the newsgroup.


hes joking (some "the other" James S Harris thing).


His joke didn't make any sense in the c.l.c context.
additionally, if you looked at the original poster you would see he has "James
Harris" <no.email.please>, therefore private correspondence is out of the
question.


And do you have the slightest clue about what this means? It means that
the OP is not interested in *any* discussions of a private nature (among
other things). Therefore, kal should have taken the hint.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #28

P: n/a
Dan Pop wrote:
additionally, if you looked at the original poster you would see he has
"James Harris" <no.email.please>, therefore private correspondence is out of
the question.


And do you have the slightest clue about what this means? It means that
the OP is not interested in *any* discussions of a private nature (among
other things). Therefore, kal should have taken the hint


not necessarily. i do not show my email address on newsgroups (when possible) as
i got hit very hard by the last SWEN worm (SWEN is NEWS spelt backwards... a
reference to its email collection method) and spammers often use newsgroups to
collect email addresses. this does not mean i am against private correspondence.
Nov 14 '05 #29

P: n/a
Ronald Landheer-Cieslak <ro****@landheer.com> wrote:
James Harris wrote:
Advice on which is or is not thought to be acceptable would be much appreciated. Please
bear in mind that I intend these names for commands/instructions as well as variables and
types. Constants would be in all caps.
There's no reason to make constants all-caps, by the way: why would you
want to do that?


For one thing, because of the difference between

#define TWICE(i) ((i)+(i))

int x, y=4;
x=TWICE(y++);

and

int twice(int i)
{
return i+i;
}

int x, y=4;
x=twice(y++);

Making all #defined macros, both object- and function-like, all-caps, is
generally considered a good idea because they can have quite different
semantics from ordinary objects and functions.

Richard
Nov 14 '05 #30

P: n/a
Richard Bos wrote:
Ronald Landheer-Cieslak <ro****@landheer.com> wrote:

James Harris wrote:

Advice on which is or is not thought to be acceptable would be much appreciated. Please
bear in mind that I intend these names for commands/instructions as well as variables and
types. Constants would be in all caps.


There's no reason to make constants all-caps, by the way: why would you
want to do that?

For one thing, because of the difference between

#define TWICE(i) ((i)+(i))

int x, y=4;
x=TWICE(y++);

and

int twice(int i)
{
return i+i;
}

int x, y=4;
x=twice(y++);

Making all #defined macros, both object- and function-like, all-caps, is
generally considered a good idea because they can have quite different
semantics from ordinary objects and functions.

Almost convincing ;)

Thing is: macros that evaluate their parameters more than once are evil:
they shouldn't be written in the first place. Basically, macros that
have different semantics than their equivalent functions are confusing
and therefore harmful.

Macros *can* be good, but some *definitely* aren't.

Just my $0.02 CAN

rlc
Nov 14 '05 #31

P: n/a
Dan Pop wrote:
In <2m************@uni-berlin.de> Ronald Landheer-Cieslak <ro****@landheer.com> writes:

There's no reason to make constants all-caps, by the way: why would you
want to do that?

To make it obvious that they are constants and, therefore, usable in
constant expressions. As an additional bonus, the programmers would be
less tempted to change their values ;-)

The compiler will holler if you try to use non-constants in constant
expressions and if you try to change constants. The const-ness of an
identifier should be obvious from its function (e.g. a maximal anything
doesn't change, nor does a minimal anything, etc.). You don't need
all-caps for that.

rlc
Nov 14 '05 #32

P: n/a
In <20040721210510.038605ca@localhost> Sam Halliday <em***@example.com> writes:
Dan Pop wrote:
>additionally, if you looked at the original poster you would see he has
>"James Harris" <no.email.please>, therefore private correspondence is out of
>the question.


And do you have the slightest clue about what this means? It means that
the OP is not interested in *any* discussions of a private nature (among
other things). Therefore, kal should have taken the hint


not necessarily. i do not show my email address on newsgroups (when possible) as
i got hit very hard by the last SWEN worm (SWEN is NEWS spelt backwards... a
reference to its email collection method) and spammers often use newsgroups to
collect email addresses. this does not mean i am against private correspondence.


People who are not against private communication provide a garbled
email address and an algorithm for degarbling it. You've got dozens of
examples in this very newsgroup. Not doing that means exactly one thing:
complete lack of interest in private communication.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #33

P: n/a
Dan Pop wrote:
Sam Halliday writes:
Dan Pop wrote:
>additionally, if you looked at the original poster you would see he has
>"James Harris" <no.email.please>, therefore private correspondence is out

of> >the question.

And do you have the slightest clue about what this means? It means that
the OP is not interested in *any* discussions of a private nature (among
other things). Therefore, kal should have taken the hint


not necessarily. i do not show my email address on newsgroups (when possible)
as i got hit very hard by the last SWEN worm (SWEN is NEWS spelt backwards...
a reference to its email collection method) and spammers often use newsgroups
to collect email addresses. this does not mean i am against private
correspondence.


People who are not against private communication provide a garbled
email address and an algorithm for degarbling it. You've got dozens of
examples in this very newsgroup. Not doing that means exactly one thing:
complete lack of interest in private communication.


thats unsound logic. it does not mean exactly one thing at all. it means that
"lack of interest in private communication" is one possible explanation.
Nov 14 '05 #34

P: n/a
Ronald Landheer-Cieslak <ro****@landheer.com> writes:
[...]
Thing is: macros that evaluate their parameters more than once are
evil: they shouldn't be written in the first place. Basically, macros
that have different semantics than their equivalent functions are
confusing and therefore harmful.

Macros *can* be good, but some *definitely* aren't.


I think that's over-stating it a bit.

Macros that evaluate their parameters more than once impose a cost in
terms of maintainability. But there are circumstances in which that
cost is worthwhile. The getc macro in <stdio.h> is a good example of
this; by allowing the stream argument to be evaluated more than once,
it saves the overhead of a function call in most cases.

(An inline function might have been a better way to do this, but C
didn't have inline functions before C99.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #35

P: n/a
In <20040722152141.380383b9@noss> Sam Halliday <em***@example.com> writes:
Dan Pop wrote:
Sam Halliday writes:
>Dan Pop wrote:
>> >additionally, if you looked at the original poster you would see he has
>> >"James Harris" <no.email.please>, therefore private correspondence is out
>of> >the question.
>>
>> And do you have the slightest clue about what this means? It means that
>> the OP is not interested in *any* discussions of a private nature (among
>> other things). Therefore, kal should have taken the hint
>
>not necessarily. i do not show my email address on newsgroups (when possible)
>as i got hit very hard by the last SWEN worm (SWEN is NEWS spelt backwards...
>a reference to its email collection method) and spammers often use newsgroups
>to collect email addresses. this does not mean i am against private
>correspondence.


People who are not against private communication provide a garbled
email address and an algorithm for degarbling it. You've got dozens of
examples in this very newsgroup. Not doing that means exactly one thing:
complete lack of interest in private communication.


thats unsound logic. it does not mean exactly one thing at all. it means that
"lack of interest in private communication" is one possible explanation.


The only *sensible* one.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #36

P: n/a
In <2m************@uni-berlin.de> Ronald Landheer-Cieslak <ro****@landheer.com> writes:
Dan Pop wrote:
In <2m************@uni-berlin.de> Ronald Landheer-Cieslak <ro****@landheer.com> writes:

There's no reason to make constants all-caps, by the way: why would you
want to do that? To make it obvious that they are constants and, therefore, usable in
constant expressions. As an additional bonus, the programmers would be
less tempted to change their values ;-)

The compiler will holler if you try to use non-constants in constant
expressions and if you try to change constants.
But not the other way round: if the maintainer fails to realise that the
identifier is a constant that could be used in a constant expression,
there is no one to tell him about it.
The const-ness of an
identifier should be obvious from its function (e.g. a maximal anything
doesn't change, nor does a minimal anything, etc.).
In C, there is more than way of defining such constants:

#define MAXVAL 1000 /* MAXVAL can be used in constant expressions */
vs
const int maxval = 1000; /* no maxval in constant expressions */
You don't need all-caps for that.


Even if you don't need them, they certainly help. Have a look at the
constants defined in <limits.h> and <float.h> and see how many of them
aren't all caps.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #37

P: n/a
In <2m************@uni-berlin.de> Ronald Landheer-Cieslak <ro****@landheer.com> writes:
Thing is: macros that evaluate their parameters more than once are evil:
they shouldn't be written in the first place.
Sez who?
Basically, macros that
have different semantics than their equivalent functions are confusing
and therefore harmful.
That's why they're spelled all caps: to avoid having them confused with
functions. If you know you're "calling" a function-like macro, you
don't expect function call semantics and avoid side effects in the
arguments. No confusion and, therefore, no harm. Such macros can still
be very useful and it is sheer stupidity to avoid them simply because you
can't implement them with function semantics.
Macros *can* be good, but some *definitely* aren't.


Indeed. The ones that actually mess with the language syntax (see
"algol.h" in the original Bourne shell source code) are to be avoided
like the plague, outside of IOCCC contests.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #38

P: n/a
Keith Thompson wrote:
Ronald Landheer-Cieslak <ro****@landheer.com> writes:
[...]
Thing is: macros that evaluate their parameters more than once are
evil: they shouldn't be written in the first place. Basically, macros
that have different semantics than their equivalent functions are
confusing and therefore harmful.

Macros *can* be good, but some *definitely* aren't.

I think that's over-stating it a bit.

Macros that evaluate their parameters more than once impose a cost in
terms of maintainability. But there are circumstances in which that
cost is worthwhile. The getc macro in <stdio.h> is a good example of
this; by allowing the stream argument to be evaluated more than once,
it saves the overhead of a function call in most cases.

(An inline function might have been a better way to do this, but C
didn't have inline functions before C99.)

An inline function would have been a better way to do that and since
they exist since C99, why not use them and declare macros that evaluate
their parameters more than once a no-no..?

rlc
Nov 14 '05 #39

P: n/a
Dan Pop wrote:
In <2m************@uni-berlin.de> Ronald Landheer-Cieslak <ro****@landheer.com> writes:
Thing is: macros that evaluate their parameters more than once are evil:
they shouldn't be written in the first place.

Sez who?

Erhm.. let's see:
"In <2m************@uni-berlin.de> Ronald Landheer-Cieslak writes:"
^^^^^^^^^^^^^^^^^^^^^^^
I guess that would be me ;)
Basically, macros that
have different semantics than their equivalent functions are confusing
and therefore harmful.

That's why they're spelled all caps: to avoid having them confused with
functions. If you know you're "calling" a function-like macro, you
don't expect function call semantics and avoid side effects in the
arguments. No confusion and, therefore, no harm. Such macros can still
be very useful and it is sheer stupidity to avoid them simply because you
can't implement them with function semantics.

In my experience, one can hardly ever rely on a naming convention to be
followed correctly & completely.

That aside, if you have to look up the semantics of your macros every
time you use them, just because they're macros, don't you think you're
kinda defeating the purpose of your macro?

In most cases, inline functions would do just as nicely without the
trouble that macros can cause (and C99 allows them, so why not use them?)
Macros *can* be good, but some *definitely* aren't.

Indeed. The ones that actually mess with the language syntax (see
"algol.h" in the original Bourne shell source code) are to be avoided
like the plague, outside of IOCCC contests.

At least we agree on that :)

rlc
Nov 14 '05 #40

P: n/a
Dan Pop wrote:
In <2m************@uni-berlin.de> Ronald Landheer-Cieslak writes:
Dan Pop wrote:
In <2m************@uni-berlin.de> Ronald Landheer-Cieslak writes:
There's no reason to make constants all-caps, by the way: why would you
want to do that?
To make it obvious that they are constants and, therefore, usable in
constant expressions. As an additional bonus, the programmers would be
less tempted to change their values ;-)

The compiler will holler if you try to use non-constants in constant
expressions and if you try to change constants.

But not the other way round: if the maintainer fails to realise that the
identifier is a constant that could be used in a constant expression,
there is no one to tell him about it.

I the maintainer fails to realize that a constant is a constant from the
name of the variable, which, I repeat, should be named for its
functionality, then the variable is probably not named clearly enough.
Failing that, you may have a point ;)
The const-ness of an identifier should be obvious from its function
e.g. a maximal anything doesn't change, nor does
a minimal anything, etc.).

In C, there is more than way of defining such constants:

#define MAXVAL 1000 /* MAXVAL can be used in constant expressions */
vs
const int maxval = 1000; /* no maxval in constant expressions */

Yeah, that would be a quirk in C.. The following makes your point nicely:
http://www.embedded.com/story/OEG20011220S0063

IMHO, C++ is right here: a constant expression should accept *any*
constant (i.e. anything of which the value is known at compile-time).
You don't need all-caps for that.

Even if you don't need them, they certainly help. Have a look at the
constants defined in <limits.h> and <float.h> and see how many of them
aren't all caps.

I do not necessarilly concur with all the choices the committee-people
make - especially where style is concerned.

That said, the first two of the three points you made seem pertinent
enough to concur w/ naming
constants-suitable-for-use-in-constant-expressions in all-caps. That
would go for #defined constants and enums..

Still not convinced for macros, though (even though I usually do name
them in all-caps, BTW ;) ).

rlc
Nov 14 '05 #41

P: n/a
Ronald Landheer-Cieslak <ro****@landheer.com> writes:
Keith Thompson wrote:
Ronald Landheer-Cieslak <ro****@landheer.com> writes:
[...]
Thing is: macros that evaluate their parameters more than once are
evil: they shouldn't be written in the first place. Basically, macros
that have different semantics than their equivalent functions are
confusing and therefore harmful.

Macros *can* be good, but some *definitely* aren't.

I think that's over-stating it a bit.
Macros that evaluate their parameters more than once impose a cost in
terms of maintainability. But there are circumstances in which that
cost is worthwhile. The getc macro in <stdio.h> is a good example of
this; by allowing the stream argument to be evaluated more than once,
it saves the overhead of a function call in most cases.
(An inline function might have been a better way to do this, but C
didn't have inline functions before C99.)

An inline function would have been a better way to do that and since
they exist since C99, why not use them and declare macros that
evaluate their parameters more than once a no-no..?


That's fine if you can assume that your code will only be compiled
with C99 compilers (or at least with compilers that implement inline
functions with C99-compatible syntax and semantics). That's not
always a safe assumption.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #42

P: n/a
Ronald Landheer-Cieslak <ro****@landheer.com> wrote:
Richard Bos wrote:
Making all #defined macros, both object- and function-like, all-caps, is
generally considered a good idea because they can have quite different
semantics from ordinary objects and functions.

Almost convincing ;)

Thing is: macros that evaluate their parameters more than once are evil:
they shouldn't be written in the first place.


In theory, I agree. In practice, please write a swap macro without
evaluating at least one of the parameters more than once.

Richard
Nov 14 '05 #43

P: n/a
In <2m************@uni-berlin.de> Ronald Landheer-Cieslak <ro****@landheer.com> writes:
Keith Thompson wrote:
Ronald Landheer-Cieslak <ro****@landheer.com> writes:
[...]
Thing is: macros that evaluate their parameters more than once are
evil: they shouldn't be written in the first place. Basically, macros
that have different semantics than their equivalent functions are
confusing and therefore harmful.

Macros *can* be good, but some *definitely* aren't.

I think that's over-stating it a bit.

Macros that evaluate their parameters more than once impose a cost in
terms of maintainability. But there are circumstances in which that
cost is worthwhile. The getc macro in <stdio.h> is a good example of
this; by allowing the stream argument to be evaluated more than once,
it saves the overhead of a function call in most cases.

(An inline function might have been a better way to do this, but C
didn't have inline functions before C99.)

An inline function would have been a better way to do that and since
they exist since C99, why not use them and declare macros that evaluate
their parameters more than once a no-no..?


Clue: function-like macros can do things functions (inline or not) cannot
do. Write the function implementing the functionality of the following
macro:

#define MIN(n1, n2) ((n1) < (n2) ? (n1) : (n2))

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #44

P: n/a
In <2m************@uni-berlin.de> Ronald Landheer-Cieslak <ro****@landheer.com> writes:
Dan Pop wrote:
In <2m************@uni-berlin.de> Ronald Landheer-Cieslak <ro****@landheer.com> writes:
Thing is: macros that evaluate their parameters more than once are evil:
they shouldn't be written in the first place. Sez who?

Erhm.. let's see:
"In <2m************@uni-berlin.de> Ronald Landheer-Cieslak writes:"
^^^^^^^^^^^^^^^^^^^^^^^
I guess that would be me ;)


The semantics of this idiomatic question are: what are your credentials?
Basically, macros that
have different semantics than their equivalent functions are confusing
and therefore harmful.

That's why they're spelled all caps: to avoid having them confused with
functions. If you know you're "calling" a function-like macro, you
don't expect function call semantics and avoid side effects in the
arguments. No confusion and, therefore, no harm. Such macros can still
be very useful and it is sheer stupidity to avoid them simply because you
can't implement them with function semantics.

In my experience, one can hardly ever rely on a naming convention to be
followed correctly & completely.
In my experience, competent programmers never break a naming convention
without a *good* reason.
That aside, if you have to look up the semantics of your macros every
time you use them, just because they're macros, don't you think you're
kinda defeating the purpose of your macro?
Nope, you simply assume that each and every parameter can be multiply
evaluated. Even if this is not the case NOW, it might be in a future
version of the macro.
In most cases, inline functions would do just as nicely without the
trouble that macros can cause (and C99 allows them, so why not use them?)


1. Because I have no conforming C99 compiler.

2. Because macros can do things functions cannot. I have already provided
an example, in another post in this thread.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #45

P: n/a
Keith Thompson wrote:
Ronald Landheer-Cieslak <ro****@landheer.com> writes:
Keith Thompson wrote:
Ronald Landheer-Cieslak <ro****@landheer.com> writes:
[...]
Thing is: macros that evaluate their parameters more than once are
evil: they shouldn't be written in the first place. Basically, macros
that have different semantics than their equivalent functions are
confusing and therefore harmful.

Macros *can* be good, but some *definitely* aren't.

I think that's over-stating it a bit.
Macros that evaluate their parameters more than once impose a cost in
terms of maintainability. But there are circumstances in which that
cost is worthwhile. The getc macro in <stdio.h> is a good example of
this; by allowing the stream argument to be evaluated more than once,
it saves the overhead of a function call in most cases.
(An inline function might have been a better way to do this, but C
didn't have inline functions before C99.)


An inline function would have been a better way to do that and since
they exist since C99, why not use them and declare macros that
evaluate their parameters more than once a no-no..?

That's fine if you can assume that your code will only be compiled
with C99 compilers (or at least with compilers that implement inline
functions with C99-compatible syntax and semantics). That's not
always a safe assumption.

Granted, in which case function-like macros are a necessary evil ;)

rlc
Nov 14 '05 #46

P: n/a
Dan Pop wrote:
In <2m************@uni-berlin.de> Ronald Landheer-Cieslak <ro****@landheer.com> writes:

Keith Thompson wrote:

Ronald Landheer-Cieslak <ro****@landheer.com> writes:
[...]
Thing is: macros that evaluate their parameters more than once are
evil: they shouldn't be written in the first place. Basically, macros
that have different semantics than their equivalent functions are
confusing and therefore harmful.

Macros *can* be good, but some *definitely* aren't.
I think that's over-stating it a bit.

Macros that evaluate their parameters more than once impose a cost in
terms of maintainability. But there are circumstances in which that
cost is worthwhile. The getc macro in <stdio.h> is a good example of
this; by allowing the stream argument to be evaluated more than once,
it saves the overhead of a function call in most cases.

(An inline function might have been a better way to do this, but C
didn't have inline functions before C99.)


An inline function would have been a better way to do that and since
they exist since C99, why not use them and declare macros that evaluate
their parameters more than once a no-no..?

Clue: function-like macros can do things functions (inline or not) cannot
do. Write the function implementing the functionality of the following
macro:
#define MIN(n1, n2) ((n1) < (n2) ? (n1) : (n2))

In C, that is impossible, but that doesn't change that, IMHO, C is
broken in this respect.

Again, a necessary evil in this case, but *only* in case you actually
*need* a "function" that can basically take any type as parameter, which
IMHO is (or should be) rarely the case (or in which case you just might
need a different language, such as C++).

Now, don't get me wrong: I can understand that you may need such macros
from time to time, and in the cases where the macros evaluate their
parameters more than once, IMHO, the maintainer should be notified in
some way (i.e. by naming the macro in all-caps, for example).

The point I'm trying to make is:
* one should avoid writing macros that evaluate their parameters more
than once
* there is no reason to name *all* macros in all-caps (but that doesn't
mean that *none* should be named in all-caps

rlc
Nov 14 '05 #47

This discussion thread is closed

Replies have been disabled for this discussion.