Variable naming conventions.
pereges
opinion, are good naming convetions for variables ? Can you please
give an example or two ?
vipp...@gmail.com
I like to prefix my variables with O0318_
William Pursell
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:
{
char *fn; /* first name */
...
}
**ONLY IF** the total number of new lines between the opening brace
and
the closing brace is small enough that the comment will be visible
98% of the time a person sees fn in use. And fn should probably
appear in only a few places. Even then it is questionable.
Code for readability. If you are coding to save keystrokes,
stop coding. (Besides, any reasonable editor will autocomplete
names for you, so there really is no excuse to use short names.)
John Floren
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
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.
--
HTH,
James
James Harris
I should have said, some people like to include type information as
part of the name, either at the beginning or the end.
--
James
Richard Heathfield
<snip>
> I should have said, some people like to include type information as
> part of the name, either at the beginning or the end.
There should be a law against that.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Keith Thompson
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.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
CBFalconer
> James Harris said:
>
> <snip>
>
>> I should have said, some people like to include type information
>> as part of the name, either at the beginning or the end.
>
> There should be a law against that.
Except for pointers.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Ian Collins
> Richard Heathfield wrote:
>> James Harris said:
>>
>> <snip>
>>
>>> I should have said, some people like to include type information
>>> as part of the name, either at the beginning or the end.
>> There should be a law against that.
>
> Except for pointers.
>
--
Ian Collins.
William Pursell
> Richard Heathfield wrote:
> > James Harris said:
>
> >> I should have said, some people like to include type information
> >> as part of the name, either at the beginning or the end.
>
> > There should be a law against that.
>
> Except for pointers.
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.
Chris M. Thomasson
news:lnhc9ta...@nuthaus.mib.org...
> pereges <Bro...@gmail.com> writes:
>> 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.
=^D
James Harris
But what about (and I'm not recommending this; only asking the
question)
int value;
int *value_p;
--
James
James Harris
> > James Harris said:
>
> > <snip>
>
> >> I should have said, some people like to include type information
> >> as part of the name, either at the beginning or the end.
>
> > There should be a law against that.
>
> Except for pointers.
What about types:
size_t
?
--
James
Ian Collins
--
Ian Collins.
santosh
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
"William Pursell" <bill.p...@gmail.com> wrote in message
news:02416ca8-6ebe-4465...@k7g2000hsd.googlegroups.com...
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.
--
Bartc
CBFalconer
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
>>
>>> 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.
>
> =^D
This doesn't appear to be responsive :-)
Richard Tobin
Ian Collins <ian-...@hotmail.com> wrote:
>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
--
Please remember to mention me / in tapes you leave behind.
s0s...@gmail.com
> On 9 Aug, 13:27, pereges <Brol...@gmail.com> wrote:
>
> > 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 ?
>
> 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
William Pursell
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. 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. (2 reasons: editors will auto-complete for you,
and the focus should be on maintainability, not on typing
speed.)
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.
s0s...@gmail.com
> On 10 Aug, 15:20, s0s...@gmail.com wrote:
>
> > > 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).
>
> 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
Richard Harter
<ian-...@hotmail.com> wrote:
>James Harris wrote:
>> On 10 Aug, 07:14, William Pursell <bill.purs...@gmail.com> wrote:
>>> On 10 Aug, 04:16, CBFalconer <cbfalco...@yahoo.com> wrote:
>>>
>>>> Richard Heathfield wrote:
>>>>> James Harris said:
>>>>>> I should have said, some people like to include type information
>>>>>> as part of the name, either at the beginning or the end.
>>>>> There should be a law against that.
>>>> Except for pointers.
>>> That's absurd. Treating pointers specially just adds to the
>>> beginner's perception that they are somehow mysterious.
Richard, may I take it that your view is that, not confusing
beginner's is more important than writing clean, clear code. I
assume that you don't believe any such thing, but, in effect,
that seems to be your argument.
>>>
>>> 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;
This looks like a special case where you have two variables with
one being a pointer to the other. I'm not sure that one should
ever do that; the problem is that the notation states a
relationship that can be violated in the code.
>>
>It's pretty obvious a pointer's a pointer by the way its used.
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 complex code with several levels of indirection and variables
having differing degrees of "pointerness" determining the
pointerness of a variable by inspection can be tricky.
Offhand, I don't see any harm in appending a _p to indicate a
pointer, a _pp to indicate a pointer to pointer, etc.
William Pursell
With this convention, which is correct?
int ** value_p;
--or--
int ** value_pp;
I can see some added value to embedding type information in the
name (although I dislike it), but I don't think it is wise
to treat pointers differently. It is obfuscatious.
Richard Harter
<bill.p...@gmail.com> wrote:
>On 10 Aug, 08:58, James Harris <james.harri...@googlemail.com> wrote:
>> On 10 Aug, 07:14, William Pursell <bill.purs...@gmail.com> wrote:
>> > On 10 Aug, 04:16, CBFalconer <cbfalco...@yahoo.com> wrote:
>>
>> > > Richard Heathfield wrote:
>> > > > James Harris said:
>>
>> > > >> I should have said, some people like to include type information
>> > > >> as part of the name, either at the beginning or the end.
>>
>> > > > There should be a law against that.
>>
>> > > Except for pointers.
>>
>> > That's absurd. =A0Treating 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)
>>
>> =A0 int value;
>> =A0 int *value_p;
>
>With this convention, which is correct?
>int ** value_p;
>--or--
>int ** value_pp;
The latter. The value of the convention, such as it might be,
lies in making explicit the degree of indirection.
>
>I can see some added value to embedding type information in the
>name (although I dislike it), but I don't think it is wise
>to treat pointers differently. It is obfuscatious.
Perhaps you could spell out exactly why you think it would be
"obfuscatious".
One argument against it is that if the convention isn't
universally followed in the code then it could be a source of
confusion rather than an aid.
Contrarywise to that argument one could use the rule that the _p
_pp, etc, convention is only used when one wants to make it clear
in the name what the level of indirection is.
Walter Roberson
William Pursell <bill.p...@gmail.com> wrote:
>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".
--
"I feel sorry for the person who can't get genuinely excited
about his work. Not only will he never be satisfied, but he will
never achieve anything worthwhile." -- Walter Chrysler
Ian Collins
> On Sun, 10 Aug 2008 20:03:22 +1200, Ian Collins
> <ian-...@hotmail.com> wrote:
>
>> It's pretty obvious a pointer's a pointer by the way its used.
>
> 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.
--
Ian Collins.
pereges
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.
blargg
<a6a334d8-f65f-4b38...@b1g2000hsg.googlegroups.com>,
s0s...@gmail.com wrote:
> [snip objections that William Pursell was stating opinion as fact]
Sebastian, I re-read William Pursell's post you replied to and he was very
careful to avoid stating opinion as fact. Maybe English isn't your native
language? Here's a breakdown (and yes, I have too much time, so no need to
point that out), with <> added for grouping, and [] as added comments:
Yes, you can say one is better than the other. Such a statement
["one is better than the other"] 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. [Maybe you tripped
up on this sentence? He's providing "using underscores as a
separator is better than mixed case" as an example statement,
noting that it's a statement of preference.] There is much
disagreement about the claim that <mixed case is as readable as
underscore separators> (I happen to find mixed case pretty
unreadable.) [Here again, he's noting that there is disagreement
among people about this particular claim, and in parenthesis, he's
noting his preference.] I've met very few people who find
underscores to be unreadable, but many who find mixed case to be
ugly. [Again, an objective fact; he's reporting the expressed
preference of other people he's met. What they expressed is a fact
about what they prefer.] 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.) [Here he expressed an
opinion, clearly prefixed, and included objective reasons why one
might adopt the same preference]
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
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
[...]
> 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
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
> August Karlstrom <fusio...@comhem.se> writes:
[...]
>> 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
> On 9 Aug, 13:27, pereges <Brol...@gmail.com> wrote:
> > 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 ?
>
> 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