Naming convention?
 

I have been using for Java for a long time, now need to write some C+
+,

It seems to me that naming conventnio in C++ is quite different from
Java (in fact, any recommended standard?)

e.g. Java style

Class MyClass {
int someValue;
void someMethod
}

C++ Style

Class MyClass
{
int m_some_value;
void some_method
}

Re: Naming convention?
 

"howa" <howachen@gmail.com> wrote in message
news:1174716348.288971.194390@l77g2000hsb.googlegr oups.com...
>I have been using for Java for a long time, now need to write some C+
> +,
>
> It seems to me that naming conventnio in C++ is quite different from
> Java (in fact, any recommended standard?)
>
> e.g. Java style
>
> Class MyClass {
> int someValue;
> void someMethod
> }
>
> C++ Style
>
> Class MyClass
> {
> int m_some_value;
> void some_method
> }

There are many diferent naming conventions used for C++ and only some are
agreed on. However.
int m_some_value;
is pretty much agreed that polish notation is dead. It was tried and didn't
work well.

A lot of people (myself included) add a training underscore to private
variables of a class. Capitalization is another thing that people don't
universially follow one way or another. Personally, I would use SomeValue.
Some people would use someValue, although I've never understood why.
Some_Value users would seem to be in the minority.

I am one of the very few people who still use polish notation for class
names. So I personally would do it this way:

class CMyClass
{
public:
int Value() { return Value_; }
private:
int Value_;
};

Although most would probably agree that the "normal" way would probably be:

class MyClass
{
public:
int Value() { return Value_; }
private:
Value_;
};

Everyone pretty much agrees, however, never preceed a variable name with an
underscore. I.E. This is bad:

_Value;

There are many cases where a preceeding underscore followed by somethign
else is reserved by the implementation. In this particular case, an
underscore followed by a capital letter is reserved. Some would use _value;
which isn't strictly reserved, but could be some day. So best bets are:
just don't do it.

Re: Naming convention?
 

On 24 Mar, 06:05, "howa" <howac...@gmail.com> wrote:
> I have been using for Java for a long time, now need to write some C+
> +,
>
> It seems to me that naming conventnio in C++ is quite different from
> Java (in fact, any recommended standard?)
>
> e.g. Java style
>
> Class MyClass {
> int someValue;
> void someMethod
>
> }
>
> C++ Style
>
> Class MyClass
> {
> int m_some_value;
> void some_method
> }

That's a possible style. It happens not to be my personal preference.
Also, C++ keywords are all lower case so that should be class, not
Class.

Apart from that, there is no single recommended style. I don't think
there is any single body with the authority to recommend one. The most
important thing is to be consistent. When I am doing my own projects,
I use my personally preferred style consistently. When I am working in
an existing project, I use whatever style is prevalent consistently.
So if I came to work on your project and you'd been using the style
you show above, that's they style I would use. The fact that it's not
exactly the style I'd choose is irrelevant.

There are a couple of specific practices that you might find helpful:

In certain contexts, names containing a double underscore or starting
with an underscore are reserved to the implementation. If you make
sure that names you use never contain a double underscore or start
with one, you guarantee never to have a naming conflict of that nature
with the implementation.

Similarly, an often recommended practice is to always use ALL_CAPS for
macros and never use ALL_CAPS for anything else. That way, you
effectively create a namespace for macros and you reduce the risk of a
macro stomping all over your code. You don't eliminate the risk
completely because your implementation, or any third party code you
use, might not follow this practice. But you avoid making the problem
any worse.

Gavin Deane

Re: Naming convention?
 

Dnia Fri, 23 Mar 2007 23:54:57 -0700, Jim Langston napisa³(a):

> int m_some_value;
> is pretty much agreed that polish notation is dead.

Isn't it called 'hungarian notation'?
Polish notation [and reverse polish notation] is for expressions ;)
I.e. '2 + 2' in PN is '+ 2 2' and in RPN is '2 2 +' .

> A lot of people (myself included) add a training

trailing ;)

> underscore to private variables of a class.

I personally don't like names with leading or trailing underscores,
because it's easy to overlook them or confuse with other syntax.
But in the middle [separating words, when space isn't allowable] is OK.

> Capitalization is another thing that people don't universially
> follow one way or another. Personally, I would use SomeValue.
> Some people would use someValue, although I've never understood why.

To differentiate object names from type names and method names.
I'm trying to use convention that object names start with small letter,
and the beginnings of the following words start with capital leter.
For type and function names the same, but I start with capital leter.
Then I always know where I have object name, and where the type name.
Example:

class GraphicsMode //new type name
{
public:
unsigned int ScreenWidth() const { return screenWidth; }
unsigned int ScreenHeight() const { return screenHeight; }
void ScreenWidht(unsigned int newScreenWidth); //set new width
void ScreenHeight(unsigned int newScreenHeight); //set new height
...
private:
unsigned int screenWidth;
unsigned int screenHeight;
...
};

//Now it's easy to see where is a type name, and where is object name.
GraphicsMode currentGraphicsMode;

//It's even possible to do the following, and it's stil clear.
GraphicsMode graphicsMode;

graphicsMode.ScreenWidth(123);
graphicsMode.ScreenHeight( currentGraphicsMode.ScreenHeight() );

> Some_Value users would seem to be in the minority.

Yes. Because capitalization of first letter is enough information
to not confuse the particular words. Then the undesrcore would be
redundant ;)

> I am one of the very few people who still use polish notation for class
> names. So I personally would do it this way:
>
> class CMyClass
> {
> public:
> int Value() { return Value_; }
> private:
> int Value_;
> };

Hungarian notation has a one big flaw: when you want to change
the type of the name, you have to find-and-replace in the whole
source code [often in a whole bunch of source files].
What if you consider one day, that CMyClass is too simple for
a class, and it will be better as a plain old struct? Will you
find-and-replace all CMyClass to change it to SMyClass?

And it's in the most cases redundant to use hungarian notation,
because you're doing the compiler's work. It's a compiler's duty
to watch for a types of objects, not the programmer's.
It's better to write program by the way that you can know the
type of object from a context, not from prefixes.

> Everyone pretty much agrees, however, never preceed a variable
> name with an underscore. I.E. This is bad:
>
> _Value;

Yes. And it's always as strange for me, that I always know that
here's something uncommon [implementation-defined name].

--
SasQ

Re: Naming convention?
 

howa wrote:

> I have been using for Java for a long time, now need to write some C+
> +,
>
> It seems to me that naming conventnio in C++ is quite different from
> Java (in fact, any recommended standard?)

There is no naming convention is C++, the standard specifies nothing of
the sort. Many people and organizations have devised their own.

My company organization coding standard specifies:

1. Lowercase beginnings for variable name, uppercase elsewhere
2. CamelCase in all identifers where practical
3. Verb phrases for function names other than constructors/destructors
4. Trailing underscores for member variables


class MyClass
{
MyClass();
int someValue_;
void DoSomething();
};



Brian

Re: Naming convention?
 

SasQ <sasq1@go2.pl> wrote:
> Hungarian notation has a one big flaw: when you want to change
> the type of the name, you have to find-and-replace in the whole
> source code [often in a whole bunch of source files].
> What if you consider one day, that CMyClass is too simple for
> a class, and it will be better as a plain old struct? Will you
> find-and-replace all CMyClass to change it to SMyClass?
>
> And it's in the most cases redundant to use hungarian notation,
> because you're doing the compiler's work. It's a compiler's duty
> to watch for a types of objects, not the programmer's.
> It's better to write program by the way that you can know the
> type of object from a context, not from prefixes.

There are actually two types of Hungarian notation: Systems Hungarian
and Apps Hungarian. Systems uses the actual type, whereas Apps is more
for indicating the purpose.

http://en.wikipedia.org/wiki/Hungari...Apps_Hungarian

http://www.joelonsoftware.com/articles/Wrong.html
(near the bottom)


Not that I use either one.

--
Marcus Kwok
Replace 'invalid' with 'net' to reply