ClanLib 0.9 Coding Standards

[rombust]

I really like the coding standards in ClanLib. (I have used very similar standards at work for the past 11 years).

There is one exception to this: Member variables in classes

Currently, the variables can be anything. This conflicts with local functions variables names.

For Example


class MyClass
{
public:
void Test();
int window;
}

void MyClass::Test()
{
...
int window = TempWindow();
...
window = NewWindow();
...
}


The local variable is modified instead of the class member variable.

At work, I use the "m_" prefix for class member variables, with the first letter in Caps.

For example "m_Window"

Any thoughts?

(Also CODING_STYLE file needs updating to reflect doxygen style comments)

[Seth]

Agreed.

Not a big deal, but I vote for the the m_ prefix because I use it with my work projects also.

Although for me I only use caps to make words more readable:


int m_window;
bool m_bWindow;
char * m_pWindowName;
string m_windowName;

[rombust]

Actually, i use that exact method myself!!! Spooky!

[kbluck]

I've used the 'm_' prefix as well in the past. Since I started using Python, I've come to prefer their convention of just a leading underscore to signify "private" members. I also use it for "module-scope" globals and types to signify that they aren't intended for external use.

As for decorating pointer variables, I think its less important to know whether something *is* a pointer (the compiler will keep that straight) than to know what is the "ownership" of the pointer in the current context? Is it a "smart" pointer, is it "borrowed" and so should not be deleted, or is it "owned" and the current scope should delete it?

--- Kevin

[Magnus Norddahl]

I really do not like the m_ prefix, since I consider it redundant information except in situations where the code needs a clean up. I do agree that without the prefix there are occasional situations where a function name might clash with a variable, but it is fairly rare and never annoyed me personally when it happens.

There are three things in the current convention that annoy me a bit:


I know' #pragma once' is non-standard but all the compilers we use support it, so the headers would look nicer if we used that instead.
The current doxygen doc markup defines the clanGroup stuff in a way that makes it appear as garbage when you use the normal HTML output. I think if the \xml tag is used, this could probably be avoided.
Excessive use of the 'return' keyword. I once figured it would make code easier to read, but it seems to do the exact opposite. :)