C++ Programming Style Guidelines

[E. Robert Tisdale]

C++ Programming Style Guidelines

http://geosoft.no/development/cppstyle.html

I think that these guidelines are almost *all* wrong.
For example:

11. Private class variables should have underscore suffix.
class SomeClass {
private:
int length_;
}

12. Generic variables should have the same name as their type.
void setTopic (Topic *topic)
// NOT: void setTopic (Topic *value)
// NOT: void setTopic (Topic *aTopic)
// NOT: void setTopic (Topic *x)

void connect (Database *database)
// NOT: void connect (Database *db)
// NOT: void connect (Database *oracleDB)

7. The terms get/set must be used
where an attribute is accessed directly.
employee.getNam e(); matrix.getEleme nt (2, 4);
employee.setNam e (name); matrix.setEleme nt (2, 4, value);

[David Lee Conley]

"E. Robert Tisdale" <E.************ **@jpl.nasa.gov > wrote in message
news:d8******** **@nntp1.jpl.na sa.gov...

C++ Programming Style Guidelines

http://geosoft.no/development/cppstyle.html

I think that these guidelines are almost *all* wrong.
For example:

11. Private class variables should have underscore suffix.
class SomeClass {
private:
int length_;
}

12. Generic variables should have the same name as their type.
void setTopic (Topic *topic)
// NOT: void setTopic (Topic *value)
// NOT: void setTopic (Topic *aTopic)
// NOT: void setTopic (Topic *x)

void connect (Database *database)
// NOT: void connect (Database *db)
// NOT: void connect (Database *oracleDB)

7. The terms get/set must be used
where an attribute is accessed directly.
employee.getNam e(); matrix.getEleme nt (2, 4);
employee.setNam e (name); matrix.setEleme nt (2, 4, value);

I definitely don't agree with #7. I may be new to this, but I'm pretty sure
this violates one of the basic principles of OOD: polymorphism. Why use two
names for a function when you can overload it?

employee.Name() ; matrix.Element( 2, 4);
employee.Name(n ame); matrix.Element( 2, 4, value);

Dave

[Fraser Ross]

"E. Robert Tisdale"

C++ Programming Style Guidelines

http://geosoft.no/development/cppstyle.html

I think that these guidelines are almost *all* wrong.
For example:

11. Private class variables should have underscore suffix.
class SomeClass {
private:
int length_;
}
It doesn't say why not to do this with all class members and I don't know a
reason.
7. The terms get/set must be used
where an attribute is accessed directly.
employee.getNam e(); matrix.getEleme nt (2, 4);
employee.setNam e (name); matrix.setEleme nt (2, 4, value);

The functions have different purposes so I agree with giving them different
names.

Fraser.

[Howard]

"David Lee Conley" <co********@ear thlink.net> wrote in message
news:ti******** ********@newsre ad3.news.atl.ea rthlink.net...

7. The terms get/set must be used
where an attribute is accessed directly.
employee.getNam e(); matrix.getEleme nt (2, 4);
employee.setNam e (name); matrix.setEleme nt (2, 4, value);

I definitely don't agree with #7. I may be new to this, but I'm pretty
sure this violates one of the basic principles of OOD: polymorphism. Why
use two names for a function when you can overload it?

employee.Name() ; matrix.Element( 2, 4);
employee.Name(n ame); matrix.Element( 2, 4, value);

Dave

I disagree. Polymorphism has to do with objects of different types
accomplishing the same task with their own methods, such as a Rectangle and
a Circle both performing a Draw function. The task is to"draw". How they
do it is what differs. And that's accomplished by overriding virtual
functions, not by overloading.

(That's run-time polymorphism, anyway. There's also compile-time
polymorphism, using templates, but again, that has to do with working with
different types, not making one name stand for different actions on a single
type.)

A function called "Name" tells you nothing... it's not a verb, which is what
a function name should usually be. It should tell you what it does.

Also, suppose you want to have a default parameter for your function? How
would you accomplish that in your scenario? You can't, because leaving out
the name (or value) parameter suddenly changes the meaning of the function
call from a setter to a getter.

If you use accessor functions, then calling them getWhatever and setWhatever
sound like perfectly reasonable requirements to me. Giving them just the
name of the member variable does not.

-Howard

[David Lee Conley]

"Howard" <al*****@hotmai l.com> wrote in message
news:10******** *************@b gtnsc04-news.ops.worldn et.att.net...

"David Lee Conley" <co********@ear thlink.net> wrote in message
news:ti******** ********@newsre ad3.news.atl.ea rthlink.net...

7. The terms get/set must be used
where an attribute is accessed directly.
employee.getNam e(); matrix.getEleme nt (2, 4);
employee.setNam e (name); matrix.setEleme nt (2, 4, value);

I definitely don't agree with #7. I may be new to this, but I'm pretty
sure this violates one of the basic principles of OOD: polymorphism. Why
use two names for a function when you can overload it?

employee.Name() ; matrix.Element( 2, 4);
employee.Name(n ame); matrix.Element( 2, 4, value);

Dave

I disagree. Polymorphism has to do with objects of different types
accomplishing the same task with their own methods, such as a Rectangle
and a Circle both performing a Draw function. The task is to"draw". How
they do it is what differs. And that's accomplished by overriding virtual
functions, not by overloading.

(That's run-time polymorphism, anyway. There's also compile-time
polymorphism, using templates, but again, that has to do with working with
different types, not making one name stand for different actions on a
single type.)

A function called "Name" tells you nothing... it's not a verb, which is
what a function name should usually be. It should tell you what it does.

Also, suppose you want to have a default parameter for your function? How
would you accomplish that in your scenario? You can't, because leaving
out the name (or value) parameter suddenly changes the meaning of the
function call from a setter to a getter.

If you use accessor functions, then calling them getWhatever and
setWhatever sound like perfectly reasonable requirements to me. Giving
them just the name of the member variable does not.

-Howard

You're right. I should've put more thought into it. My bad.

Dave

[John Dibling]

E. Robert Tisdale wrote:

I think that these guidelines are almost *all* wrong.
I agree, and here's one I particularly hate:
49. [snip] Note that structs are kept in C++ for compatibility with C only,
and avoiding them increases the readability of the code by reducing the number of constructs used. Use a class instead.

This implies that it's never correct to define a datatype that is just
a bag of bits, such as:

struct Name
{
std::string m_sFirst, m_sLast;
};

This implication is nonsensical and overly restrictive. The fact that
C++ gives the programmer many ways to accomplish a given task is a
*good* thing, not a bad thing. Everything must not necesarrily be a
full-fledged object.

[Shezan Baig]

John Dibling wrote:

E. Robert Tisdale wrote:

I think that these guidelines are almost *all* wrong.

I agree, and here's one I particularly hate:

49. [snip] Note that structs are kept in C++ for compatibility with C only,
and avoiding them increases the readability of the code by reducing the number of constructs used. Use a class instead.

This implies that it's never correct to define a datatype that is just
a bag of bits, such as:

struct Name
{
std::string m_sFirst, m_sLast;
};

This implication is nonsensical and overly restrictive. The fact that
C++ gives the programmer many ways to accomplish a given task is a
*good* thing, not a bad thing. Everything must not necesarrily be a
full-fledged object.

You guys should read the "disclaimer " at the beginning, goes something
like this:

"The attempt is to make a guideline, not to force a particular coding
style onto individuals."

The intent of this document is just to serve as a guideline to make
code across an organisation "look" the same. Obviously none of these
guidelines will be important if you're coding a simple 200 line
application.

But when you are creating Large Scale C++ Software, it *does* help to
follow some sort of guideline (and the guidelines in this document seem
mostly reasonable to me). Think 20 years down the line.

hth,
-shez-

[Howard]

"John Dibling" <jd******@gmail .com> wrote in message
news:11******** **************@ g49g2000cwa.goo glegroups.com.. .

E. Robert Tisdale wrote:

I think that these guidelines are almost *all* wrong.

I agree, and here's one I particularly hate:

49. [snip] Note that structs are kept in C++ for compatibility with C
only,
and avoiding them increases the readability of the code by reducing the
number of constructs used. Use a class instead.

This implies that it's never correct to define a datatype that is just
a bag of bits, such as:

struct Name
{
std::string m_sFirst, m_sLast;
};

This implication is nonsensical and overly restrictive. The fact that
C++ gives the programmer many ways to accomplish a given task is a
*good* thing, not a bad thing. Everything must not necesarrily be a
full-fledged object.

What are you talking about? How is a struct not a "full-fledged object",
but "just a bag of bits"? The only differences between structs and classes
is the default visibility and default inheritance. The above sample is the
same as this:

class Name
{
public:
std::string m_sFirst, m_sLast;
};

I seem to recall that some early versions of C++ (such as Turbo C++, I
believe) defined struct and class differently, where a struct was just a
data holder (i.e., POD) and a class could include methods. But that is not
the case any more at all (and I don't know if it was ever the standard).

I see many people still using struct when all they want is a data holder. I
suspect that's for a few reasons. One, they used to do it that way, back
when their compiler required it. Two, they like the convenience of the
default public visibility for struct members (avoiding typing "public:"
every time). And three, it gives a quick visual clue that to them (and to
others who are used to this style) as to whether they're looking at an
object which simply holds some data, or one which has functionality of its
own.

But there's no requirement as to which you should use. You could use struct
everywhere and class nowhere, and as long as you specified the desired
inheritance and visibility, they'll accomplish the very same task.

One more thing: when you don't specify a constructor, destructor, etc. for
a struct or class, the compiler will generate a default one for you. So
really, even a "plain old struct" has *some* functionality.

My personal preference is to use struct only for POD data, and make
everything else a class. (Why? For the three reasons I gave earlier.)

Hmm... I guess that means I disagree with that rule, also. I just disagree
with your argument as to why struct should be kept. I want to keep it
because I like to use it, that's all. It's certainly not needed.

-Howard

[John Dibling]

Shezan Baig wrote:

The intent of this document is just to serve as a guideline to make
code across an organisation "look" the same. [snip] when you are
creating Large Scale C++ Software, it *does* help to follow some sort
of guideline (and the guidelines in this document seem
mostly reasonable to me). Think 20 years down the line.
I agree, coding guidelines are a good thing. But I believe that coding
guidelines should encourage programmers to generate better code, not
better *looking* code.

Here's an example. The guidelines state:
75. The if-else class of statements should have the following form:
if (condition) {
statements;
}

if (condition) {
statements;
}
else {
statements;
}

I see no benefit whatsoever from this recommendation, and don't think
that this kind of thing should appear in any coding guideline document,
even if it's just a "should." It simply can't help Joe Programmer to
write better code. The first if block is identical to:

if( condition )
{
statements;
}

....which is how I personally write such blocks. There's no difference!
In fact, if a coding guideline tells me I can't write my if blocks the
way I naturally do, I'll end up taking much longer to write code
becasue I'll have to correct what naturally falls out of my brain to
fit some pedantic mandate.

Moreover, a professional programmer should be expected to be able to
maintain other peoples' code just as easily as thier own, even if it
doesn't look like thier own, so long as the code isn't insanly
convoluted.

Instead of these sorts of style recommendations , I believe coding
guidelines should include things like:

"Prefer std::string to dynamically-allocated char buffers."

....or...

"Check all incoming pointer paraaters for validity before using them."

Take care,

John Dibling

[fuzzylollipop]

because .Name() != .Name(name)

one is a "getter" the other a "setter"

it is definately NOT good OO style to do it the way you are
recommending since everyone else has already agreed to do it the other
( more readable ) way.