Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > New coding standards: use underscores, hyphens or mixed case in command (and identifier) names

Reply
Thread Tools

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

 
 
Ronald Landheer-Cieslak
Guest
Posts: n/a
 
      07-22-2004
Dan Pop wrote:
> In <(E-Mail Removed)> Ronald Landheer-Cieslak writes:
>>Dan Pop wrote:
>>>In <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      07-22-2004
Ronald Landheer-Cieslak <(E-Mail Removed)> writes:
> Keith Thompson wrote:
> > Ronald Landheer-Cieslak <(E-Mail Removed)> 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) http://www.velocityreviews.com/forums/(E-Mail Removed) <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.
 
Reply With Quote
 
 
 
 
Richard Bos
Guest
Posts: n/a
 
      07-23-2004
Ronald Landheer-Cieslak <(E-Mail Removed)> 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
 
Reply With Quote
 
Dan Pop
Guest
Posts: n/a
 
      07-23-2004
In <(E-Mail Removed)> Ronald Landheer-Cieslak <(E-Mail Removed)> writes:

>Keith Thompson wrote:
>
>> Ronald Landheer-Cieslak <(E-Mail Removed)> 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: (E-Mail Removed)
 
Reply With Quote
 
Dan Pop
Guest
Posts: n/a
 
      07-23-2004
In <(E-Mail Removed)> Ronald Landheer-Cieslak <(E-Mail Removed)> writes:

>Dan Pop wrote:
>
>> In <(E-Mail Removed)> Ronald Landheer-Cieslak <(E-Mail Removed)> 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 <(E-Mail Removed)> 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: (E-Mail Removed)
 
Reply With Quote
 
Ronald Landheer-Cieslak
Guest
Posts: n/a
 
      07-23-2004
Keith Thompson wrote:

> Ronald Landheer-Cieslak <(E-Mail Removed)> writes:
>
>>Keith Thompson wrote:
>>
>>>Ronald Landheer-Cieslak <(E-Mail Removed)> 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
 
Reply With Quote
 
Ronald Landheer-Cieslak
Guest
Posts: n/a
 
      07-23-2004
Dan Pop wrote:

> In <(E-Mail Removed)> Ronald Landheer-Cieslak <(E-Mail Removed)> writes:
>
>
>>Keith Thompson wrote:
>>
>>
>>>Ronald Landheer-Cieslak <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
hyphens in variable names Paul Hepworth Ruby 7 07-07-2006 04:48 PM
how to transform a list form of hyphens to an html unordered list ibiza ASP .Net 5 02-09-2006 04:10 PM
Re: "Soft" hyphens Augustus HTML 4 06-25-2003 10:58 PM
Re: "Soft" hyphens Jukka K. Korpela HTML 0 06-24-2003 08:05 AM
Re: "Soft" hyphens spaghetti HTML 0 06-24-2003 07:36 AM



Advertisments