case sensitivity

[T. William Wells]

In article <1831 at etive.ed.ac.uk> sam at lfcs.ed.ac.uk (S. Manoharan) writes:
:     Bill ({ uunet | novavax } !twwells!bill) writes:
: >I use the case of identifiers to tell me some important bits of
: >information about the identifier that are not properly conveyed by the
: >name.  Here's my table:
:
:
: >Having these distinctions made consistently makes reading the code
: much easier.
: >
:
: Having two ids foo and FOO that mean  two different things will sure
: lead to confusion. If one accepts this,

Only if confusion is possible to begin with. I agree that having ids
foo and FOO where the two might be confused is a bad idea, but just
having them isn't. For example, there is little wrong with this:

typedef struct {
	...
} FOO;

	FOO     *foo;

Though I'd never write such (I'd call the pointer foop), there isn't
any possible way to confuse FOO with foo.

Be that as it may, I don't usually have names that differ only in
case. This is (almost) not intentional, it is an artifact of other
considerations. Going back to my original table, let me add some
comments:

identifier      a local variable, a function, or structure or union member

	Locals are usually short, with just enough letters in them to
	make them mnemonic. Function names are usually long and
	spelled out. Structure and union members usually have a prefix
	relating them to their structures. Variables and members tend
	to be nouns; functions, verbs.

Identifier      a global variable

	These are usually long and spelled out. These tend to be
	nouns.

IDENTIFIER      a #define constant, a typedef name, or a tag

	#define names typically have an identifying prefix that is not
	used elsewhere. Typedef names and tags typically have a name
	whose semantic characteristics distinguish are such that
	other names don't have the same spelling.  #define names are
	often nouns, typedef nouns tend to be adjectives.

identifier(...) a function-like macro

	These are often long and spelled out. They tend to be verbs.

IDENTIFIER(...) a macro that evaluates its arguments more than once,
		references locals, or does other wierd things

	These are often long and spelled out. These tend to be verbs.

As you can see, there is little scope for duplicating the spelling of
names with but case for difference. Because of these consideratios,
even in the occasional case that I do duplicate, there is rarely the
possibility of confusing the reader.

Confusion is the bottom line: if it is the case that I have two names
that are similar enough that the reader might be confused, I will
change one of them. This applies to more than just case differences.
Consider the difference between foo1 and fool. The confusion argument
against case sensitivity would, consistently applied, also require us
to consider `1' to be the same as 'l'. Hah. To hell with such
ideological reasoning, just make the code easy to understand!

BTW, I do make it a point to have globals and other externals differ
after case is stripped. One must, for portability. I'm told, e.g.,
that when you compile code for Microsoft Windows, you must tell the
linker to ignore case because of some stupidity that Microsoft did.

---
Bill                            { uunet | novavax } !twwells!bill