ISO Studies of underscores vs MixedCase in Ada or C++

[Andy Glew]

I am in search of any rigourous,
scientific, academic or industrial studies
comparing naming conventions in
C++ or similar languages such as
Ada:

Specifically, are names formed with
underscores more or less readable
than names formed with MixedCase
StudlyCaps camelCase?

....and similarly, any measurements
of programmer productivity, bug rate,
etc.; although IMHO readability matters
most.
* Religion - NOT?!

I understand that this is a religious issue
for many programmers, an issue of programming style.
I am not interested in a religious war.
I obviously have my own opinion, but I am
open to scientific evidence.
* Ada Studies?

I thought that I had seen studies like
this in some of the early design documents
for Ada, but I have not been able to find
such references on the web. Which is not
entirely surprising, since Ada was designed
prior to the web.

The Ada 83 and 95 Quality Guidelines recommend
underscores to improve readability, but provide
no source justifying this statement.
* What such studies might look like

Simple readability and recall:
- present a test subject with
a list of compound words
formed with underscoresand mixed case
- remove the list, and ask test subject
to write it
- score on accuracy

Program debugging
- present programs that are otherwise identical,
differing only in their use of underscores/MixedCase
to test subject programmers (e.g. a CS class)
- program has a known bug
- ask test subjects to find bug
- score on accuracy locating bug

Cruel TA study:
- Two sections of a CS class
- Enforce programming standards,
underscores vs MixedCase
- Pose a programming problem
- Score according to success
completing assignment

Empirical:
- Given version control databases
of large programs, some written in underscore
style, others in MixedCase
- Total bug rates normalized by LOC, name count, etc.
- OR: count only bugs that can be attributed
(after inspection of checkins) to misnamed variables

For that matter, I would be interested in any surveys
folks may have done that count projects and their
coding standards, possibly weighted
- open source (e.g. sourceforge)
- industrial
- textbooks, weighted by sales
- websites of coding standards, weighted by Google score...
Although this is less convincing than a rigorous study.
* Explanation of Newsgroups Chosen

I hope it is obvious why I have chosen these
newsgroups to post this search to:

comp.software-eng, comp.programmin g,
- an issue of software engineering
comp.lang.c++,
- the language I am most interested in
comp.lang.ada
- because I vaguely recall historical work

[Isaac Gouy]

an*******@amd.c om (Andy Glew) wrote in message news:<2c******* *************** ****@posting.go ogle.com>...

I am in search of any rigourous,
scientific, academic or industrial studies
comparing naming conventions in
C++ or similar languages such as
Ada:
- SNIP -
I hope it is obvious why I have chosen these
newsgroups to post this search to:

comp.software-eng, comp.programmin g,
- an issue of software engineering
comp.lang.c++,
- the language I am most interested in
comp.lang.ada
- because I vaguely recall historical work

Maybe the "Psychology of Programming Interest Group" mailing list
would be a good place to ask?
http://www.ppig.org/lists.html

[Programmer Dude]

Peter Ammon wrote:

classmethod :
access_specifie r
method_type_spe cifier
method_return_t ype_specifier
method_declarat ion
method_body
You've piqued my interest, since I'm the first to admit that my
grammar specifications are hard to read.

Where do you put the action in the above code?

classmethod :
access_specifie r
method_type_spe cifier
method_return_t ype_specifier
method_declarat ion
method_body
{ doSomething(); }

I thought this was a grammar definition? I'd have thought that

method_body :== { doSomething(); }

But if they are different, the way you did it seems fine to me.
What if there's more than one reduction possible?

classmethod :
access_specifie r
method_type_spe cifier
method_return_t ype_specifier
method_declarat ion
method_body
{ doSomething(); }
| something_else
another_thing
even_more
blah_blah
{ doSomethingElse (); }

Probably break them up in some fashion:

class-method:
class-method-normal |
class-method-extended

class-method-normal:
access-specifier
method-type-specifier
method-return-type-specifier
method-declaration
method-body

class-method-extended:
something-else
another-thing
even-more
blah-blah

(In proportional fonts, hyphens are usually skinnier than
underscores and (to my eye) make the text more readable.
It's not as noticable with monospace fonts, but I think the
lower example looks better (read: more readable :-).)

Agreed! I wish that more languages allowed hyphen use in
identifiers. Dylan is the only one I can think of off the
top of my head.

Others have already mentioned Lisp, so I don't have to!
(Well,... *didn't* have to... :-)

--
|_ CJSonnack <Ch***@Sonnack. com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ _______________ ____| Call: 1-800-DEV-NULL |
|______________ _______________ _______________ _|_____________ __________|

[Stephen Baynes.]

> takeAction(doYo uMind.ifI(openT heWindow));

take_action (do_you_mind.if _i (open_the_windo w));

take_Action (do_You_Mind.if _I(open_The_Win dow));

Take_Action (Do_You_Mind.If _I (Open_The_Windo w));

Once you start looking at the readability whole expressions, you also need
to look at the use of spaces. The above are not consistant about if a space
is used with round brackets. [And then there is the question - is it more
readable with the space outside or inside the bracket - my preference is for
inside - so the opening bracket is with the function name rather than the
first parameter.]
Take_Action (Do_You_Mind.If _I (Open_The_Windo w));
Take_Action(Do_ You_Mind.If_I(O pen_The_Window) );
Take_Action( Do_You_Mind.If_ I( Open_The_Window ) );

To go back to the original question - there have been studies that showed
underscores gave the most readable results - unfortunately I have lost the
reference and I would also like to get my hands on it again.

-
Stephen Baynes CEng MBCS
My views are my own

"Georg Bauhaus" <ge***@strudel. futureapps.de> wrote in message
news:86******** ****@strudel.fu tureapps.de...

[Jakob Bieling]

"Jacob Sparre Andersen" <sp****@crs4.it > wrote in message
news:3F******** ******@crs4.it. ..

Jakob Bieling wrote:

"Leif Roar Moldskred" <rm******@onlin e.no> wrote in message
news:86******** ****@huldreheim .huldreskog.no. ..

"Jakob Bieling" <ne*****@gmy.ne t> writes:

Ah, I did not consider this difference even. *g* My point was,

checking my own identifier names for spelling errors based on natural language rules is a bad idea.

Why. They are hopefully spelled correctly. Otherwise you are adding an
unneeded complication to reading and understanding your code.

Instead, a special code-spell-checker would be great:

a/ 'Created' identifiers are automatically added to the list of known words (for the current compilation run only)

I wouldn't like that. Incorrectly spelled identifiers make code
maintenance more difficult.

I do not know how you choose your identifier names, but I usually give
them abbreviated prefixes, which would make every spell-checker flag a
misspelling. See Kevin's example (news:3f******* *@nntp2.nac.net )

b/ When an identifier is used, but not found, the spell-checker tries to find out what I meant (like any spell-checker)

Would certainly be nice. But doing a proper job here basically means
trying to compile the code. If you decide to ignore visibility rules,
things will of course become much simpler.

Right. You got me thinking here, though. Since the code is
sort-of-spell-checked by the compiler already, point a and b are pretty much
superflous (unless you want the luxury of the compiler trying to guess the
correctly spelled identifier name). No need for a special spell-checker
anymore, except that it should only spell-check comments ;)

regards
--
jb

(replace y with x if you want to reply by e-mail)

[Mike Wahler]

"Jakob Bieling" <ne*****@gmy.ne t> wrote in message
news:bm******** *****@news.t-online.com...

correctly spelled identifier name). No need for a special spell-checker
anymore, except that it should only spell-check comments ;)

I often refer to identifier names in my comments,
so back to the original problem. :-)

-Mike

[Georg Bauhaus]

In comp.lang.ada Stephen Baynes. <st************ @soton.sc.phili ps.com> wrote:
: Once you start looking at the readability whole expressions, you also need
: to look at the use of spaces. The above are not consistant about if a space
: is used with round brackets.

Glad someone noticed, explicitly :-) Has anybody written Algol
programs (using spaces in identifiers)?
Georg

[Jacob Sparre Andersen]

Jakob Bieling wrote:

"Jacob Sparre Andersen" <sp****@crs4.it > wrote in message
news:3F******** ******@crs4.it. ..

I wouldn't like that. Incorrectly spelled identifiers make code
maintenance more difficult.

I do not know how you choose your identifier names, but I usually give
them abbreviated prefixes,

I practically never use abbreviations or acronyms in identifiers -
except for those from the project specific "approved" list ("IO" is
always there, though :). And when I do, it is always as separate parts
like in "Integer_Text_I O". I would never write "IntegerTextIO" ,
"intTextIO" or "Int_Text_I O" in my code.

If you want more details on how I choose my identifier names, then
chapter 3 in »Ada Quality and Style« is hopefully a good description.

Greetings,

Jacob
--
There only exist 10 kinds of people: Those who know binary
numbers and those who don't know binary numbers.

[Jakob Bieling]

"Jacob Sparre Andersen" <sp****@crs4.it > wrote in message
news:3F******** ******@crs4.it. ..

Jakob Bieling wrote:

"Jacob Sparre Andersen" <sp****@crs4.it > wrote:

I wouldn't like that. Incorrectly spelled identifiers make code
maintenance more difficult.

I do not know how you choose your identifier names, but I usually give them abbreviated prefixes,

I practically never use abbreviations or acronyms in identifiers -

Not sure where I picked that habit up, but I guess it is pure laziness.
I could not imagine having to type those long names everytime you use them.
Especially counter variables in for-loops (posting from comp.lang.c++) ..
you also use simple i's and j's etc. there, right? As you seem to be posting
from comp.lang.ada, I am not too sure if Ada provides such constructs in the
same way C++ does, so maybe Ada has different means of looping in a
for-loop-kind-of-way (yes, I know pretty much nothing about Ada).

Also, sometimes I tend to abbreviate quite a lot, so that later I might
not know what it stands for. In cases like those I just put a comment next
to where I declared the variable and I can keep saving those keystrokes.

regards
--
jb

(replace y with x if you want to reply by e-mail)

[Jakob Bieling]

"Mike Wahler" <mk******@mkwah ler.net> wrote in message
news:2z******** *********@newsr ead4.news.pas.e arthlink.net...

"Jakob Bieling" <ne*****@gmy.ne t> wrote in message
news:bm******** *****@news.t-online.com...

correctly spelled identifier name). No need for a special spell-checker
anymore, except that it should only spell-check comments ;)

I often refer to identifier names in my comments,
so back to the original problem. :-)

Ok, so we do need a scope-less list of identifier names :p
--
jb

(replace y with x if you want to reply by e-mail)

[Peter Bushell]

"Jakob Bieling" <ne*****@gmy.ne t> wrote in message
news:bm******** *****@news.t-online.com...

"Jacob Sparre Andersen" <sp****@crs4.it > wrote in message
news:3F******** ******@crs4.it. ..

Also, sometimes I tend to abbreviate quite a lot, so that later I might not know what it stands for. In cases like those I just put a comment next
to where I declared the variable and I can keep saving those keystrokes.

If you can't remember what it meant, pity the poor engineer who has to
maintain your code when you've gone! Having to look up a declaration every
few seconds is not acceptable.

There is evidence* to suggest that 80% of programming is (or should be)
thinking time. Saving keystrokes is therefore not an issue.

Regards,

Peter Bushell.

* My source was Glass, Robert L., "Facts and Fallacies of Software
Engineering". His source was some research material published in another of
his books: "Software Creativity".