Variable naming conventions.

[santosh]

Re: Variable naming conventions.

James Harris wrote:

On 10 Aug, 04:16, CBFalconer <cbfalco...@yah oo.comwrote:

>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.

>
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]

Re: Variable naming conventions.


"William Pursell" <bill.pursell@g mail.comwrote in message
news:02416ca8-6ebe-4465-b483-f042da7b883c@k7 g2000hsd.google groups.com...

On 10 Aug, 04:16, CBFalconer <cbfalco...@yah oo.comwrote:

>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.

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]

Re: Variable naming conventions.

Ian Collins wrote:

CBFalconer wrote:

>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.

>
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(myhas h, &myitem);
if (!p) err_recovery();
else /* worked */ {
/* do your thing */
}

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[CBFalconer]

Re: Variable naming conventions.

"Chris M. Thomasson" wrote:

"Keith Thompson" <kst-u@mib.orgwrote in message

>pereges <Broli00@gmail. comwrites:
>>

>>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 :-)

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[Richard Tobin]

Re: Variable naming conventions.

In article <6g7lm9Fel467U9 @mid.individual .net>,
Ian Collins <ian-news@hotmail.co mwrote:

>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.

[s0suk3@gmail.com]

Re: Variable naming conventions.

On Aug 9, 10:03 am, William Pursell <bill.purs...@g mail.comwrote:

On 9 Aug, 13:27, pereges <Brol...@gmail. comwrote:
>

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]

Re: Variable naming conventions.

On 10 Aug, 15:20, s0s...@gmail.co m wrote:

On Aug 9, 10:03 am, William Pursell <bill.purs...@g mail.comwrote:

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. 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.

[s0suk3@gmail.com]

Re: Variable naming conventions.

On Aug 10, 10:33 am, William Pursell <bill.pursell@g mail.comwrote:

On 10 Aug, 15:20, s0suk3@gmail.co m wrote:
>

On Aug 9, 10:03 am, William Pursell <bill.pursell@g mail.comwrote:

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]

Re: Variable naming conventions.

On Sun, 10 Aug 2008 20:03:22 +1200, Ian Collins
<ian-news@hotmail.co mwrote:

>James Harris wrote:

>On 10 Aug, 07:14, William Pursell <bill.purs...@g mail.comwrote:

>>On 10 Aug, 04:16, CBFalconer <cbfalco...@yah oo.comwrote:
>>>
>>>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 "pointernes s" 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]

Re: Variable naming conventions.

On 10 Aug, 08:58, James Harris <james.harri... @googlemail.com wrote:

On 10 Aug, 07:14, William Pursell <bill.purs...@g mail.comwrote:

On 10 Aug, 04:16, CBFalconer <cbfalco...@yah oo.comwrote:

>

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.

>
But what about (and I'm not recommending this; only asking the
question)
>
  int value;
  int *value_p;

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]

Re: Variable naming conventions.

On Sun, 10 Aug 2008 10:11:24 -0700 (PDT), William Pursell
<bill.pursell@g mail.comwrote:

>On 10 Aug, 08:58, James Harris <james.harri... @googlemail.com wrote:

>On 10 Aug, 07:14, William Pursell <bill.purs...@g mail.comwrote:

On 10 Aug, 04:16, CBFalconer <cbfalco...@yah oo.comwrote:

>>

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
"obfuscatio us".

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]

Re: Variable naming conventions.

In article <1b5c40f6-9529-4951-8119-bfe378b7ac7c@x3 5g2000hsb.googl egroups.com>,
William Pursell <bill.pursell@g mail.comwrote:

>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 multidimensiona l 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]

Re: Variable naming conventions.

Richard Harter wrote:

On Sun, 10 Aug 2008 20:03:22 +1200, Ian Collins
<ian-news@hotmail.co mwrote:
>

>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]

Re: Variable naming conventions.

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

[Keith Thompson]

Re: Variable naming conventions.

CBFalconer <cbfalconer@yah oo.comwrites:
[...]

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.

--
Keith Thompson (The_Other_Keit h) kst-u@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"