Variable naming conventions.

[Ian Collins]

Pointerness isn't always obvious when inspecting a line or two of
code. For example, in

x = y;

we know that x and y have the same type, modulo implicit
promotions, but we don't know whether they are pointers or not.

In cases like that, we probably don"t care.

 

[pereges]

What about variables that shoulf hold temporrary results ?
I tend to use some simple names like p, temp, tempstore, i etc etc

 

[Keith Thompson]

For example I often develop a type where I need both the item and a
pointer to it. I.E:

typedef struct sometype {
....
} sometype, *sometypep;

Since this has to do with naming types I may not be responsive to
the original query.

[...]

If the code using sometypep needs to be aware that it's a pointer to
sometype, it should just use ``sometype*'' or ``struct sometype*''.

If the code using sometypep doesn't need to be aware that it's a
pointer to sometype (i.e., you're using sometypep as an opaque type),
it should have a name that reflects how it's used, not what it is.

 

[CBFalconer]

.... snip ...

I've been handed large (50k+ lines) weakly structured programs
to maintain and develop; some of the programs were in languages
that were dynamically typed. More than once I found that the only
effective way to tame the code was to do a vigerous variable
renaming that incorporated typing information in the new variable
names, so that when I read the code it would be much more obvious
when there was a type mismatch (and there inevitably were type
mismatches )

The first stage of that process is the renaming, after which you
recompile as a check. That renaming is greatly eased by id2id.
See:

<http://cbfalconer.home.att.net/download/id2id-20.zip>

for the package, in source form.

 

[Richard Bos]

Why?

Because you often want a variable for the current object, _and_ a
pointer to the next object in the list (or something similar). In that
case, you might want

object this_object, *p_next_object;

Other solutions are possible and may even be preferable, but in this
case, I don't find the above objectionable /per se/. Microsoftian
Hungarian Notation, OTOH, is anathema.

Richard

 

[August Karlstrom]

William Pursell wrote:
[...]

There is much disagreement about the claim
that mixed case is as readable as underscore separators (I
happen to find mixed case pretty unreadable.) I've met very
few people who find underscores to be unreadable, but many
who find mixed case to be ugly. The only complaint I've ever
heard about using underscores is that it's harder to type
the name, and in my opinion that is an utterly vacuous
complaint.

Compare the expressions

(1) last_row - first_row

(2) lastRow - firstRow

(3) lastrow - firstrow

Visually, in (1) the underscore tends to separate the two variables into
four, almost as if underscore was some kind of operator. Example two and
three does not have that problem. Example three is (of course) the most
pleasing to the eye but is possibly also be the least readable of the three.

Anyway, I tend to follow the tradition of whatever language I use.


August

 

[Keith Thompson]

William Pursell wrote:
[...]

There is much disagreement about the claim
that mixed case is as readable as underscore separators (I
happen to find mixed case pretty unreadable.) I've met very
few people who find underscores to be unreadable, but many
who find mixed case to be ugly. The only complaint I've ever
heard about using underscores is that it's harder to type
the name, and in my opinion that is an utterly vacuous
complaint.

Compare the expressions

(1) last_row - first_row

(2) lastRow - firstRow

(3) lastrow - firstrow

Visually, in (1) the underscore tends to separate the two variables
into four, almost as if underscore was some kind of operator. Example
two and three does not have that problem. Example three is (of course)
the most pleasing to the eye but is possibly also be the least
readable of the three.

I don't see it that way at all. I've been using languages that use
underscores in identifiers for many many years. Because of that, I
see an underscore as something that *joins* the things on either side
of it rather than separating them. In C, "last_row" is a single name
that has two parts, just as in English "John Smith" is a single name
that has two parts.

But I suppose if you're not accustomed to using and seeing underscores
in that way, it's not going to look the same way to you as it does to
me.

Personally, I can deal with camelCase, but I prefer to use
underscores. And for some purposes (though not in C), I even like to
write identifiers Like_This. I definitely disklike the "lastrow"
style; to me, it's neither readable nor pleasing to the eye.

Anyway, I tend to follow the tradition of whatever language I use.

Good idea.

 

[August Karlstrom]

Compare the expressions

(1) last_row - first_row

(2) lastRow - firstRow

(3) lastrow - firstrow

[...]
Personally, I can deal with camelCase, but I prefer to use
underscores. And for some purposes (though not in C), I even like to
write identifiers Like_This.

If I remember correctly this is commonly used in Ada.

I definitely disklike the "lastrow"
style; to me, it's neither readable nor pleasing to the eye.

What I mean is that if we just look at the identifiers in (3) without
trying to read them there is no typographical ugliness. Moreover this
seems to be the convention used by the authors of C.


August

 

[Richard Bos]

Use all lowercase letters, and full words separated by underscores:

good examples:
char *first_name;

bad examples:
char *fn;
char *firstName;
char *frst_nm; /* ugh */

In some cases, short names may be okay as long as their scope
is less than 10 lines or so. IOW, this is okay:

Or if the short name is the habitual name of that entity in the business
for which the program is intended. For example, I would always write

if (E!=m*c*c) report_relative_error();

and never

if (liberated_energy!=destroyed_mass*speed_of_light_in_vacuum*
speed_of_light_in_vacuum)
report_relative_error();

Richard