Coding Style

[Hal Vaughan]

This is more a style question, so I know it's subjective (I hope I don't
start a religious war!), but I'm also interested to know if there is a
trend.

I've noticed that a lot of C++ code shuns lower case and basically tries to
keep variables and functions with as short a name as possible (or at least
one that's easy to type). Functions might be like this:

getval()
ldcfg()

But I've also noticed some code that uses underscores between words:

get_val()
ld_cfg()

And here's the part I'm curious about. It seems to me that more recent code
seems to have the Java influence and is a bit more focused on readability,
so it's more like this:

getVal()
loadConfig()

Is it just me, or does it seem that more code is written like this lately?

I read somewhere that a function name can be 30 characters long but only the
1st 8 characters had to be unique, but my experience with gcc is that it
does fine with the 1st 8 chars being the same (just toyed with it). Does
that have any effect on shorter names or maybe people using different
styles for names?

Just wondering...

Hal

 

[Ioannis Vranos]

This is more a style question, so I know it's subjective (I hope I don't
start a religious war!), but I'm also interested to know if there is a
trend.

I've noticed that a lot of C++ code shuns lower case and basically tries to
keep variables and functions with as short a name as possible (or at least
one that's easy to type). Functions might be like this:

getval()
ldcfg()

But I've also noticed some code that uses underscores between words:

get_val()
ld_cfg()

And here's the part I'm curious about. It seems to me that more recent code
seems to have the Java influence and is a bit more focused on readability,
so it's more like this:

getVal()
loadConfig()

Actually the last is the "camel" style. It goes like GetVal() for
functions and someVal for variables.

 

[Ian Collins]

Actually the last is the "camel" style. It goes like GetVal() for
functions and someVal for variables.

Or getVal() for functions, someVal for variables and SomeClass for classes.

Style varies between shops, with some influence from the platform
(GetVal() for functions appears to be common on windows).

 

[JoeC]

This is more a style question, so I know it's subjective (I hope I don't
start a religious war!), but I'm also interested to know if there is a
trend.

I've noticed that a lot of C++ code shuns lower case and basically tries to
keep variables and functions with as short a name as possible (or at least
one that's easy to type). Functions might be like this:

getval()
ldcfg()

But I've also noticed some code that uses underscores between words:

get_val()
ld_cfg()

And here's the part I'm curious about. It seems to me that more recent code
seems to have the Java influence and is a bit more focused on readability,
so it's more like this:

getVal()
loadConfig()

Is it just me, or does it seem that more code is written like this lately?

I read somewhere that a function name can be 30 characters long but only the
1st 8 characters had to be unique, but my experience with gcc is that it
does fine with the 1st 8 chars being the same (just toyed with it). Does
that have any effect on shorter names or maybe people using different
styles for names?

Just wondering...

Hal

I can say that I write larger programs and I try to keep names as
short as possible because it is blatantly less typing and less chance
of error. I personally like one word or I like twoWords. I don't
like to get too much longer than that. There is a question of
readability and going back to some code after some time. It does get
bad and some of the criptic var names can get confusing. Take time
write code and large programs and find a system that works for you.
Long ariable names get tedious to type especialy if you have to keep
writing them:

bitData[index++] = binTemp[0*(cur+number)] *
128 + binTemp[1*(cur+number)] *
64 + binTemp[2*(cur+number)] *
32 + binTemp[3*(cur+number)] *
16 + binTemp[4*(cur+number)] *
8 + binTemp[5*(cur+number)] *
4 + binTemp[6*(cur+number)] *
2 + binTemp[7*(cur+number)];

 

[James Kanze]

This is more a style question, so I know it's subjective (I
hope I don't start a religious war!), but I'm also interested
to know if there is a trend.

I've noticed that a lot of C++ code shuns lower case and
basically tries to keep variables and functions with as short
a name as possible (or at least one that's easy to type).

You mean shuns upper case, of course. This corresponds more or
less to the oldest traditions in C. (If you've ever listended
to the output of a source listing on a teletype, you know why
they wanted to keep the number of characters to a minimum.)
I've not seen it much in C++, except when interfacing with
older, C libraries. Even in C, today, the tendency is to use
more readable names---compare the names in the more recent parts
of Posix (e.g. pthread_mutex_lock) with those from the orginal
Unix (e.g. ioctl), for example.

Functions might be like this:

But I've also noticed some code that uses underscores between words:

And here's the part I'm curious about. It seems to me that
more recent code seems to have the Java influence and is a bit
more focused on readability,

It's not Java influenced, and it's not particularly recent.
There are a number of variations in the different conventions,
but one main division is how you separate words in a symbol:
with an underscore, or by starting each word within the symbol
with a capital letter. The difference in readability is minor
(and IMHO probably favors the underscore). The two traditions
seem to come from different sources: most of the CCITT
specifications used capital letters (the so-called CamelCase),
so companies involved in any way with telephone systems tended
to adopt that, going back to the mid 1980's, at least. There
might have been other sources as well, since I don't think Java
was connected with telephone systems at its beginnings, and it
got it from somewhere as well.

so it's more like this:

getVal()
loadConfig()

In modern C++, I'd expect to see getValue() and
loadConfiguration() (or get_value() and load_configuration()).
Use of arbitrary abbreviations more or less went out with the
teletype. Other than that, all of the conventions require macro
names to be all caps, with an underscore between words, and all
modern conventions forbid anything else from being all caps
(with the frequent exception of single letter type argument
names to templates).

Is it just me, or does it seem that more code is written like
this lately?

If by lately, you means since around 1990, maybe.

I read somewhere that a function name can be 30 characters
long but only the 1st 8 characters had to be unique, but my
experience with gcc is that it does fine with the 1st 8 chars
being the same (just toyed with it).

C and C++ have always allowed unlimited length in symbol names.
Early C did limit how many characters were significant, however,
with 31 (I think) internally, but only the first six guaranteed
accross modules (and no guarantee of case significance either).
Implementations have always been allowed to support more (and
I've never seen a C implementation which didn't support at least
eight externally). The current C standard requires 63
significant characters internally, and 31 externally (with case
always significant). C++ makes no absolute limit, but
recommends at least 1024 both internally and externally.

Does that have any effect on shorter names or maybe people
using different styles for names?

Not today.

 

[James Kanze]

Or getVal() for functions, someVal for variables and SomeClass
for classes.

Style varies between shops, with some influence from the
platform (GetVal() for functions appears to be common on
windows).

First, it's getValue() and loadConfiguration(). Modern
conventions eschew obfuscating abbreviations. Beyond that, it
probably depends on the ultimate source of the convention.
(Microsoft didn't invent anything here.) CCITT (one important
source for CamelCase), for example, used the convention that
typenames start with a capital letter, everything else with a
small. Convensions which have been taken over from earlier,
non-OO languages, where you don't have user defined types, might
very well adopt the convention of functions with a capital
letter, since they don't have any other important distinction.
(IMHO, the distinction between types and non-types is primordial
in C++, since it affects how a statement is parsed.)

 

[Yannick Tremblay]

This is more a style question, so I know it's subjective (I hope I don't
start a religious war!), but I'm also interested to know if there is a
trend.

I've noticed that a lot of C++ code shuns lower case and basically tries to
keep variables and functions with as short a name as possible (or at least
one that's easy to type). Functions might be like this:
[...chop chop]
And here's the part I'm curious about. It seems to me that more recent code
seems to have the Java influence and is a bit more focused on readability,
so it's more like this:

I think the recent focus on readability is simply because programmers
have understood the cost of unreadable code better.

I am sorry but I have to disagree with the advice and justification below:

I can say that I write larger programs and I try to keep names as
short as possible because it is blatantly less typing

Correct. This is less typing.

However:

How much of your programming time is spent typing? (hopefully only a
small percentage)
Do you type that slowly?
Can't you paste a long variable name from just above?
Have you considered IDEs/editors with auto-completion?

and less chance of error.

Huh? Why? How? Less chances of inconsequential typos, maybe assuming
that the probability of typo is directly proportional to the number of
letters but less chance of a real error (i.e. a bug): no
Two identifiers that differ only by one letter are much more likely to
be confused or mistyped than clearly worded identifiers.

e.g.:
ldCg() vs loadConfig()
ldPg() vs loadPage()

In the first case, the likelyhood that one mistype the identifier and
that this isn't picked by the compiler is quite high. This is also
likely to be overlooked by glancing over the code. There is a high
risk of it getting out of the door as a bug.

In the second case, if you do a typo, the compiler will issue an error
so be almost immediately noticed and fixed by the developer.

I personally like one word or I like twoWords. I don't
like to get too much longer than that. There is a question of
readability and going back to some code after some time. It does get
bad and some of the criptic var names can get confusing. Take time
write code and large programs and find a system that works for you.
Long ariable names get tedious to type especialy if you have to keep
writing them:

You yourself have noticed that readability is poor when you are going
going back to go you have written yourself a little while ago.
This is code you have written yourself, using your personal
style and you do have some recollection of it and you still find it
hard to maintain. If you would have to go and maintain code that
someone else who has a different style has written 2 years ago and has
now left the company, then the maintainability problems would be
ten time worse.

Also if you are writing code only for yourself, never to publish,
never to be seen by anyone else, "what works for you" might be
acceptable, but if you ever are going to be part of a team and/or
publish code, you should write code that is readable by others too.
Even if you are not currently writing code that get seen by others, it
is a good habit to take to write it as if it was going to be
maintained by someone else.

There's a quote about it:
"Always program as if your code was to be maintained by a dangerous
psychopath who knows where you live."

The part where I will agree is that overly long name do reduce
readability. So:

loadConfigFileFromHardDisk() vs loadConfig()

The former is less readable and probably obfuscate by mentionning
unimportant information.

bitData[index++] = binTemp[0*(cur+number)] *
128 + binTemp[1*(cur+number)] *
64 + binTemp[2*(cur+number)] *
32 + binTemp[3*(cur+number)] *
16 + binTemp[4*(cur+number)] *
8 + binTemp[5*(cur+number)] *
4 + binTemp[6*(cur+number)] *
2 + binTemp[7*(cur+number)];

This example is fine. But this is typically a small loop. My loop
index tend to be called "i". I don't see any advantages to using
"index" because it is:
a) such an accepted usage
b) very local scope, only inside the loop
c) declare and initialised just a few lines above and going out of
scope by the end of the scree

Howver, global variables will have a much longer much more explicit
name. Same for methods, the method name will give the user a good
idea of what it does (the contract).

Yannick

 

[JoeC]

[...chop chop]
I think the recent focus on readability is simply because programmers
have understood the cost of unreadable code better.

I am sorry but I have to disagree with the advice and justification below:

I can say that I write larger programs and I try to keep names as
short as possible because it is blatantly less typing

Correct. This is less typing.

However:

How much of your programming time is spent typing? (hopefully only a
small percentage)
Do you type that slowly?
Can't you paste a long variable name from just above?
Have you considered IDEs/editors with auto-completion?

and less chance of error.

Huh? Why? How? Less chances of inconsequential typos, maybe assuming
that the probability of typo is directly proportional to the number of
letters but less chance of a real error (i.e. a bug): no
Two identifiers that differ only by one letter are much more likely to
be confused or mistyped than clearly worded identifiers.

e.g.:
ldCg() vs loadConfig()
ldPg() vs loadPage()

In the first case, the likelyhood that one mistype the identifier and
that this isn't picked by the compiler is quite high. This is also
likely to be overlooked by glancing over the code. There is a high
risk of it getting out of the door as a bug.

In the second case, if you do a typo, the compiler will issue an error
so be almost immediately noticed and fixed by the developer.

I personally like one word or I like twoWords. I don't
like to get too much longer than that. There is a question of
readability and going back to some code after some time. It does get
bad and some of the criptic var names can get confusing. Take time
write code and large programs and find a system that works for you.
Long ariable names get tedious to type especialy if you have to keep
writing them:

You yourself have noticed that readability is poor when you are going
going back to go you have written yourself a little while ago.
This is code you have written yourself, using your personal
style and you do have some recollection of it and you still find it
hard to maintain. If you would have to go and maintain code that
someone else who has a different style has written 2 years ago and has
now left the company, then the maintainability problems would be
ten time worse.

Also if you are writing code only for yourself, never to publish,
never to be seen by anyone else, "what works for you" might be
acceptable, but if you ever are going to be part of a team and/or
publish code, you should write code that is readable by others too.
Even if you are not currently writing code that get seen by others, it
is a good habit to take to write it as if it was going to be
maintained by someone else.

There's a quote about it:
"Always program as if your code was to be maintained by a dangerous
psychopath who knows where you live."

The part where I will agree is that overly long name do reduce
readability. So:

loadConfigFileFromHardDisk() vs loadConfig()

The former is less readable and probably obfuscate by mentionning
unimportant information.

bitData[index++] = binTemp[0*(cur+number)] *
128 + binTemp[1*(cur+number)] *
64 + binTemp[2*(cur+number)] *
32 + binTemp[3*(cur+number)] *
16 + binTemp[4*(cur+number)] *
8 + binTemp[5*(cur+number)] *
4 + binTemp[6*(cur+number)] *
2 + binTemp[7*(cur+number)];

This example is fine. But this is typically a small loop. My loop
index tend to be called "i". I don't see any advantages to using
"index" because it is:
a) such an accepted usage
b) very local scope, only inside the loop
c) declare and initialised just a few lines above and going out of
scope by the end of the scree

Howver, global variables will have a much longer much more explicit
name. Same for methods, the method name will give the user a good
idea of what it does (the contract).

Yannick

Good advice. I have never worked as a team I only program for
myself. I would really like to be part of a team but I don't know
anyone who programs to work with. I don't like very long variable
names but I do try to do a better job for readability. I do cut and
paste at times. I try to stick to convention which I find more
important than length. That is get functions getVar, num cur, I
gneraly use l lp lp2 I am also trying to get use acc and dwn for x
and y which often times I mess up.