Variable naming conventions.

[pereges]

Apart from the some rules set by the C standard what , in your
opinion, are good naming convetions for variables ? Can you please
give an example or two ?

 

[vippstar]

Apart from the some rules set by the C standard what , in your
opinion, are good naming convetions for variables ? Can you please
give an example or two ?

I like to prefix my variables with O0318_

 

[John Floren]

Apart from the some rules set by the C standard what , in your
opinion, are good naming convetions for variables ? Can you please
give an example or two ?

Read "The Practice of Programming" by Kernighan and Pike. The
appropriate sections can be read at http://preview.tinyurl.com/6fpfw9
(google books), page 3.
In my opinion, all C programmers should read this book.

John

 

[James Harris]

Apart from the some rules set by the C standard what , in your
opinion, are good naming convetions for variables ? Can you please
give an example or two ?

Code Complete by Steve McConnell has a long section on data names -
pages 185 to 213. IIRC even after reading it, though, I still felt
some questions were unanswered.

FWIW the main options I think are

All lower case: filename, finaldollarbalance
Initial lower case: fileName, finalDollarBalance
Initial upper case: FileName, FinalDollarBalance
Underscore separator: file_name, final_dollar_balance
Hyphen separator (not C): file-name, final-dollar-balance

Of these the first is ok for short names (single word or single
letter) but falls down with words that can run together differently:

barbend

could be bar_bend or barb_end, for example.

Since you asked for opinions for data names I guess my preferences are
InitialUpperCase and underscore_separator.

 

[James Harris]

Code Complete by Steve McConnell has a long section on data names -
pages 185 to 213. IIRC even after reading it, though, I still felt
some questions were unanswered.

FWIW the main options I think are

All lower case: filename, finaldollarbalance
Initial lower case: fileName, finalDollarBalance
Initial upper case: FileName, FinalDollarBalance
Underscore separator: file_name, final_dollar_balance
Hyphen separator (not C): file-name, final-dollar-balance

Of these the first is ok for short names (single word or single
letter) but falls down with words that can run together differently:

barbend

could be bar_bend or barb_end, for example.

Since you asked for opinions for data names I guess my preferences are
InitialUpperCase and underscore_separator.

I should have said, some people like to include type information as
part of the name, either at the beginning or the end.

 

[CBFalconer]

James Harris said:



There should be a law against that.

Except for pointers.

 

[Keith Thompson]

Apart from the some rules set by the C standard what , in your
opinion, are good naming convetions for variables ? Can you please
give an example or two ?

If you're working on a project with others, follow any conventions
imposed by the project, even if you think they're ugly.

If you have the luxury of choosing a convention for yourself, any
choice you make will be controversial.

 

[Ian Collins]

Except for pointers.

Why?

 

[Chris M. Thomasson]

If you're working on a project with others, follow any conventions
imposed by the project, even if you think they're ugly.

If you have the luxury of choosing a convention for yourself, any
choice you make will be controversial.

=^D

 

[James Harris]

That's absurd. Treating pointers specially just adds to the
beginner's perception that they are somehow mysterious.

int value;
int *pi_value;

is inconsistent and ugly.

But what about (and I'm not recommending this; only asking the
question)

int value;
int *value_p;

 

[James Harris]

Except for pointers.

What about types:

size_t

?

 

[Ian Collins]

But what about (and I'm not recommending this; only asking the
question)

int value;
int *value_p;

It's pretty obvious a pointer's a pointer by the way its used.

 

[santosh]

What about types:

size_t

?

There is a better case to be made for types. I still don't like the _t
suffix, but it's already codified by POSIX and ISO C, so it's a widely
adopted convention by now.

PS. Note that if you're also coding to the POSIX standard, then user
defined types cannot use the _t suffix, which is reserved for the
implementation.

 

[Bartc]

That's absurd. Treating pointers specially just adds to the
beginner's perception that they are somehow mysterious.

int value;
int *pi_value;

is inconsistent and ugly.

Also misleading. You might expect pi_value to be 3.141...

Conventions do exist so that:

int *i, *j, *k;

for example is unlikely to be encountered, but:

int *p, *q, *r;

is common. Also x,y,z tend to be floating point.

 

[CBFalconer]

Why?

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. At any rate I use this in hashlib, and it
keeps the internal structure private. Thus, for the user, in
hashlib.h:

/* opaque incomplete object */
typedef struct hshtag hshtbl;

and the user enters:

hshtbl *myhash;
...
myhash = hshinit(...);
and
p = hshinsert(myhash, &myitem);
if (!p) err_recovery();
else /* worked */ {
/* do your thing */
}

 

[CBFalconer]

=^D

This doesn't appear to be responsive

 

[Richard Tobin]

It's pretty obvious a pointer's a pointer by the way its used.

And non-pointer uses almost always produce compile-time errors, so
you're not likely to miss a mistake.

-- Richard

 

[s0suk3]

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

good examples:
char *first_name;

bad examples:
char *fn;
char *firstName;

Wrong. 'firstName' is not a bad example (at least not more than your
"good" example, 'first_name'). It's underscores against camel case.
You can't say that one is better than the other, because it's strictly
a matter of preference, and because they're equivalent in terms of
readability. I, for one, would recommend camel case (seems more
elegant to me).

Sebastian

 

[s0suk3]

Yes, you can say one is better than the other.  Such a statement
is a statement of preferences, and stating that using underscores
as a separator is better than mixed case is simply a statement
of that preference.

Well of course you can say it, but you obviously can't be right about
it (which is what I meant). Since you agree that it's a statement of
preference, you should consider putting those kinds of statements as
"In my opinion, ..." Otherwise, people will interpret it as if you
meant it to be a *universally* true fact.

There is much disagreement about the claim
that mixed case is as readable as underscore separators (I
happen to find mixed case pretty unreadable.)

That's another matter that is subject to each individual. I, for one
(again , find underscores unreadable.

 I've met very
few people who find underscores to be unreadable, but many
who find mixed case to be ugly.

If we're going to look at majority, it's important to mention that the
predominating convention in most modern programming languages is mixed
case. Three notable examples are Java, C++ and C#. Also, as far as
I've seen, most important projects are developed using the mixed case
convention. A particularily popular and innovative example of this is
the browser from which you made your post, which uses that
convention.

 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.  (2 reasons: editors will auto-complete for you,
and the focus should be on maintainability, not on typing
speed.)

I agree. Typing speed is not really something to worry about, IMO.

You are absolutely correct that my initial statement is
merely an expression of personal preference.  In my opinion,
mixed case names are bad, and I strongly encourage anyone
who is adopting a naming convention to avoid them.

Now you corrected it by saying "In my opinion, ..." That's the right
statement.

Sebastian

 

[Walter Roberson]

I can see some added value to embedding type information in the
name (although I dislike it),

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 )

Within the confines of any one routine, many C compilers
can detect some issues such as mismatches in the number of
dimensions, but when you start passing around pointers to blocks
of memory that are to be treated as multidimensional arrays, C cannot
track the number of original dimensions, so using a consistant
naming convention reflecting intended number of dimensions can help
the programmer keep track of what is going on. Some people might
deal with this by using terms such as "vector" in their routine
names; there is, as far as I can see, no essential difference between
that approach and using suffixes such as "_1D".