Variable naming conventions.

[blargg]

Re: Variable naming conventions.

In article
<a6a334d8-f65f-4b38-a470-a60b1a2ba6b7@b1 g2000hsg.google groups.com>,
s0suk3@gmail.co m 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
caseis 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]

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.

[CBFalconer]

Re: Variable naming conventions.

Walter Roberson wrote:

>

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

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

[Richard Bos]

Re: Variable naming conventions.

Ian Collins <ian-news@hotmail.co mwrote:

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

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]

Re: Variable naming conventions.

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]

Re: Variable naming conventions.

August Karlstrom <fusionfile@com hem.sewrites:

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.

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

[August Karlstrom]

Re: Variable naming conventions.

Keith Thompson wrote:

August Karlstrom <fusionfile@com hem.sewrites:

[...]

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

Re: Variable naming conventions.

William Pursell <bill.pursell@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;
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_ener gy!=destroyed_m ass*speed_of_li ght_in_vacuum*
speed_of_light_ in_vacuum)
report_relative _error();

Richard