Opinion) Overuse of symbolic constants

[Sandeep Sharma]

Right from the time the first edition of K&R was released, the
advantages of using symbolic constants, as opposed to "magic numbers",
has been emphasized ---- and for good reason. I don't dispute that at
all. However, it gets on my nerves when people carry this practice
too far. Consider these examples (from the code written by a
distinguished colleague):

#define DASH '-'
#define SLASH '/'
#define SINGLE_BYTE 1

It is one thing to use symbolic constants with meaningful (and in some
cases, abstract) names, but methinks that use of symbolic constants in
this way is a complete waste. Let us take the first example. Either
the definition of DASH will never change (in which case it's usage is
superfluous) or the definition of DASH will change in the future (in
which case it will be completely misleading).
Any opinions?

--SS

[Niels Dybdahl]

> Right from the time the first edition of K&R was released, the

advantages of using symbolic constants, as opposed to "magic numbers",
has been emphasized ---- and for good reason. I don't dispute that at
all. However, it gets on my nerves when people carry this practice
too far. Consider these examples (from the code written by a
distinguished colleague):

#define DASH '-'
#define SLASH '/'
#define SINGLE_BYTE 1

It is one thing to use symbolic constants with meaningful (and in some
cases, abstract) names, but methinks that use of symbolic constants in
this way is a complete waste. Let us take the first example. Either
the definition of DASH will never change (in which case it's usage is
superfluous) or the definition of DASH will change in the future (in
which case it will be completely misleading).

I consider three important uses for defines or constants:

1. For values that are subject to change.
2. To distinguish a certain usage of a value from other usages, so that
searches are more efficient.
3. More meaningfull names (e.g. PATH_NOT_FOUND instead of a value).

I do not think that the examples shown above fits into any of these usages.

Niels Dybdahl

[Fred L. Kleinschmidt]

Sandeep Sharma wrote:

Right from the time the first edition of K?R was released, the
advantages of using symbolic constants, as opposed to "magic numbers",
has been emphasized ---- and for good reason. I don't dispute that at
all. However, it gets on my nerves when people carry this practice
too far. Consider these examples (from the code written by a
distinguished colleague):

#define DASH '-'
#define SLASH '/'
#define SINGLE_BYTE 1

It is one thing to use symbolic constants with meaningful (and in some
cases, abstract) names, but methinks that use of symbolic constants in
this way is a complete waste. Let us take the first example. Either
the definition of DASH will never change (in which case it's usage is
superfluous) or the definition of DASH will change in the future (in
which case it will be completely misleading).

Any opinions?

--SS

I use the SLASH definition to distinguish the directory name separator
for Unix vs. Windows:

#ifdef WIN32
#define SLASH '\\'
#else
#define SLASH '/'
#endif
--
Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Technical Architect, Common User Interface Services
M/S 2R-94 [phone]

[Darrell Grainger]

On Wed, 21 Apr 2004, Sandeep Sharma wrote:

Right from the time the first edition of K&R was released, the
advantages of using symbolic constants, as opposed to "magic numbers",
has been emphasized ---- and for good reason. I don't dispute that at
all. However, it gets on my nerves when people carry this practice
too far. Consider these examples (from the code written by a
distinguished colleague):

#define DASH '-'
#define SLASH '/'
#define SINGLE_BYTE 1

It is one thing to use symbolic constants with meaningful (and in some
cases, abstract) names, but methinks that use of symbolic constants in
this way is a complete waste. Let us take the first example. Either
the definition of DASH will never change (in which case it's usage is
superfluous) or the definition of DASH will change in the future (in
which case it will be completely misleading).

Any opinions?

I use macros for data that is subject to change or to make the code more
readable. Symbols are just as readable as words so I see no point in two
of the three examples.

However, the SLASH might have a place. I have seen code like:

#ifdef WINDOWS
#define SEPERATOR '\\'
#else
#define SEPERATOR '/'
#endif

Have you asked the distinguished collegue why the need for the macros? If
they have a good reason maybe a comment in the source code would be
helpful.

I'm guessing they are just blindly following something they were taught
without understanding why.

--
Send e-mail to: darrell at cs dot toronto dot edu
Don't send e-mail to vi************@ whitehouse.gov

[Martin Dickopp]

"Fred L. Kleinschmidt" <fred.l.kleinsc hmidt@nospam_bo eing.com> writes:

Sandeep Sharma wrote:

Right from the time the first edition of K?R was released, the
advantages of using symbolic constants, as opposed to "magic numbers",
has been emphasized ---- and for good reason. I don't dispute that at
all. However, it gets on my nerves when people carry this practice
too far. Consider these examples (from the code written by a
distinguished colleague):

#define DASH '-'
#define SLASH '/'
#define SINGLE_BYTE 1

It is one thing to use symbolic constants with meaningful (and in some
cases, abstract) names, but methinks that use of symbolic constants in
this way is a complete waste. Let us take the first example. Either
the definition of DASH will never change (in which case it's usage is
superfluous) or the definition of DASH will change in the future (in
which case it will be completely misleading).

Any opinions?

I use the SLASH definition to distinguish the directory name separator
for Unix vs. Windows:

#ifdef WIN32
#define SLASH '\\'
#else
#define SLASH '/'
#endif

I find this misleading. I'd prefer

#ifdef WIN32
#define DIR_SEP '\\'
#else
#define DIR_SEP '/'
#endif

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/

[Dan Pop]

In <Pi************ *************** ****@drj.pf> da*****@NOMORES PAMcs.utoronto. ca.com (Darrell Grainger) writes:

However, the SLASH might have a place. I have seen code like:

#ifdef WINDOWS
#define SEPERATOR '\\'
#else
#define SEPERATOR '/'
#endif

It was probably written by someone ignoring both English and Windows.

In most contexts, Windows accepts the forward slash as path separator.
The only exception coming to mind is COMMAND.COM (newer command
interpreters are perfectly happy with Unix-style path specifications) .

So, in a C context, it's only strings prepared to be passed to system()
that need the distinction. But such strings are typically affected by
much more important portability issues...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Jerry Coffin]

sa*********@yah oo.com (Sandeep Sharma) wrote in message news:<4c******* *************** ***@posting.goo gle.com>...

Right from the time the first edition of K&R was released, the
advantages of using symbolic constants, as opposed to "magic numbers",
has been emphasized ---- and for good reason. I don't dispute that at
all. However, it gets on my nerves when people carry this practice
too far. Consider these examples (from the code written by a
distinguished colleague):

#define DASH '-'
#define SLASH '/'
#define SINGLE_BYTE 1

It is one thing to use symbolic constants with meaningful (and in some
cases, abstract) names, but methinks that use of symbolic constants in
this way is a complete waste. Let us take the first example. Either
the definition of DASH will never change (in which case it's usage is
superfluous) or the definition of DASH will change in the future (in
which case it will be completely misleading).

I agree. To be useful, a symbolic name needs to be symbolic -- it
needs to symbolize something. These are roughly equivalent to
comments like:

a=b; /* assign b to a */

that only repeat what's already obvious. To be useful, the symbol
needs to add meaning that isn't obvious without it. A constrast would
be names like the following:

#define switch_char '-'
#define path_sep '/'

which really add meaning, as well as the flexibility of (for example)
allowing a path separator to be changed from '/' to '\\' to ':' as
appropriate.
Later,
Jerry.

--
The universe is a figment of its own imagination.

[Arthur J. O'Dwyer]

On Wed, 21 Apr 2004, Sandeep Sharma wrote in comp.lang.c:

Right from the time the first edition of K&R was released, the
advantages of using symbolic constants, as opposed to "magic numbers",
has been emphasized ---- and for good reason. I don't dispute that at
all. However, it gets on my nerves when people carry this practice
too far. Consider these examples (from the code written by a
distinguished colleague):

#define DASH '-'
#define SLASH '/'
#define SINGLE_BYTE 1

One possibility I haven't seen anyone mention yet is that while the
abstract *value* of "DASH" will never change, the *type* of "DASH"
may well change: for example, when updating this code to deal with
wide character I/O we write

#define DASH L'-'
#define SLASH L'/'
#define SINGLE_BYTE (sizeof (wchar_t))

(Here SINGLE_BYTE is a misnomer; better to name it SINGLE_CHAR or
something similar.)

A second possibility is that the first couple entries were taken
out of context from a hand-written lexer or parser:

#define DASH '-'
#define SLASH '/'
#define ASSGNOP 1000
#define STAR_ASSGNOP 1001
#define DASH_ASSGNOP 1002
#define PLUSPLUS 1003
[...]

Here we are simplifying the lexer code by making the "dash" token
equal in value to the system's '-' character, and similarly for all
other one-character tokens: multi-character tokens get their own
numerical "token" values, out of the ASCII range.
(This example code is obviously not quite portable; it's implicitly
assuming that '-' and 1000 are distinct values, which is guaranteed
by ASCII but not by Standard C.)

The already-mentioned "platform-independent directory separator"
idea is a common one, too, but I don't see how it explains the presence
of DASH along with SLASH.

HTH,
-Arthur

[Old Wolf]

"Niels Dybdahl" <nd*@fjern.dett eesko-graphics.com> wrote:

Consider these examples (from the code written by a
distinguished colleague):

#define DASH '-'
#define SLASH '/'
#define SINGLE_BYTE 1

It is one thing to use symbolic constants with meaningful (and in some
cases, abstract) names, but methinks that use of symbolic constants in
this way is a complete waste. Let us take the first example. Either
the definition of DASH will never change (in which case it's usage is
superfluous) or the definition of DASH will change in the future (in
which case it will be completely misleading).

I consider three important uses for defines or constants:

1. For values that are subject to change.
2. To distinguish a certain usage of a value from other usages, so that
searches are more efficient.
3. More meaningfull names (e.g. PATH_NOT_FOUND instead of a value).

I do not think that the examples shown above fits into any of these usages.

From a C99 implementation near you:

#define and &&
#define and_eq &=
#define bitand &
#define bitor |
#define compl ~
#define not !
#define not_eq !=
#define or ||
#define or_eq |=
#define xor ^
#define xor_eq ^=

This is interesting because a co-developer of mine has a standard include
file (predating C99 by a long way) which has:

#define AND &&
#define OR ||
#define NOT !

So I guess there is a fourth category, which the OP's definitions might
fall into: improving readability.

[CBFalconer]

Old Wolf wrote:

.... snip ...
From a C99 implementation near you:

#define and &&
#define and_eq &=
#define bitand &
#define bitor |
#define compl ~
#define not !
#define not_eq !=
#define or ||
#define or_eq |=
#define xor ^
#define xor_eq ^=

This has been in C90 since about 1995. #include <iso646.h>

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?