Re: C++ Coding Style

Hi all,
Appologies for my distinct lack of contact for the last couple of 
months. This is likely to continue for at least another couple of 
months. Though I remain interested in the project and do sparodically 
get computer access and try to follow the progress.

I think coding standards should be flexible with the basic proviso that 
code should be *readable*! It's a nice ideal to have everyone code 
identically but from a practical view point consider someone who 
contributes to 3 separate projects each with it's own conventions. Also 
if you're looking for a bug in some open source code you can't garuntee 
it will be coded your favorite way.
My preference therefore is to have broad coding guidlines for the 
project which make allowences for peoples differences. For example I do:-

int func()
{
    while(true)
    {
       proc();
    }
}

wheras some do:-

int func() {

    while ( true ) {

       proc();

    }
}

Now of course my way is the right way to do it and the other way is 
clearly wrong. But I feel it is important to tolerate other peoples 
dubious coding styles as long as they keep the code consistent and clean ;)

Low Zhen Lin wrote:

> 4 spaces per tab.
>
Yes

> '{' on a new line, flush with the previous line:
>
Yes

> ... except when hugged:
>
Personally I never hug :)

> ... or in small initialisers:
>
Yes

> ... where the insides are padded with one space on both ends.
>
Yes

> ... one space after branch control:
>
No

>
> '*' attached to typename, no spaces in declaration:
>
Yes - as per Bjarne Stroustrup.

>
> ... one space after for casting:
>
No

>
> ... no spaces in between '*':
>
Yes

> ... no spaces after for dereferencing:
>
Yes

> ... none for invoking functions:
>
Yes - I can't believe it's not compatible with MSVC++! Darn M$...

>
> '[]' attached to identifier, no spaces, always:
>
Yes

>
> '<' after 'template', space in between:
>
Yes

> Even if it is 'template <>', retain it:
>
Yes

> '<' after template name, no space in between:
>
Yes

> CamelCasing for type names, smallFirst for instance names:
>
Yes

> Space after ',', always:
>
Yes

> Labels at previous indent level: 

No. - Lables? Argh...

> ... except when the label marks off sections of code,
>
I like
switch(choice)
{
    case 0:
    {
       job();
       break;
    }
}

But Bjarne really should have made switch nicer imho...

> ~    class Object
> ~    {
> ~        public:
> ~            explicit Object();
> ~        protected:
> ~            unsigned int refCount;
> ~        private:
> ~            Object(Object&) { }
> ~    };
>
Yes

> When there is only one statement where there is normally a block, put
> the statement on the same line as the block-preceding line: 

I allways make a block but this is okay - just don't put it on a new 
line without a block.

> ~         if (o.isa(Class(String)) cout << "I got a String!" << endl;
> ~    else if (o.isa(Class(Number)) cout << "I got a Number!" << endl;
> ~    else if (o.isa(Class(Object)) cout << "I got an Object!" << endl;
> ~    else cout << "I got something wierd." << endl;
>
> Note that the 'if' lines up. When feasible, line up code to be neater:
>
This can get out of hand but I do it sometimes.

> Local variable declaration at the top of the function body, split into
> groups, seperate groups by a blank line:

Yes

> Prefer inline functions or templates to macros for code.
> Prefer macros to inline functions or templates for simple expressions.
> Always use inline functions and/or templates when parameters are
> evaluated more than once.
>
> Avoid 'using namespace' statements in headers.
>
> '.c++' for C++ source code. 'cpp' is the C preprocessor, damnit! 'cxx'
> is for badly designed filesystems. 'cc' is the C compiler, not the C++
> compiler. 'C' is indistinguishable from 'c' on Mac OS X (HFS+) and
> Windows and other 'user friendly' OSes.
> '.h' for C and C++ headers. cpp thinks they're the same.
>
> C++ class files and their headers go into the same directory.
> One class per header.
> Directory structure reflecting namespace:
>
> ~    // to get Siphonophora::ComponentKit::Core::Object
> ~    #include <Siphonophora/ComponentKit/Core/Object.h>
>
Yes

> 'I' before interface names, unless an adjective:

Personally I don't like this. The problem arises when you're on your 3rd 
iteration of development and realise you neet to refactor a Basic Class 
into an Interface Class and an Implementation Class - or vice versa and 
suddenly half the code in yourapplication breaks the naming convention. 
I think it's better to always name interfaces as adjectives or the noun 
they represent and only add bits for Implementation Classes.

eg.

class Connection
{
    public:
    void connect() = 0;
};

class ConnectionTCPIP : public Connection
{
};

I believe this is easier to manage as code changes (from a design 
perspective).
The programmer only needs to think about a Connection and never needs to 
know/care whether it is an InterfaceClass, Abstract Superclass or a 
Concrete Class.

>
> Object classes have nouns for names:
>
> ~    class Toy;
> ~    class Goo;
> ~    class BlueGoo;
>
> Functions have verbs for names:
>
> ~    size_t getSize();
> ~    void rebalanceTree();
> ~    template <typename T> T* allocate();
>
> British spelling:

Hehe...

> Always use new-style casts:

Yes

> No publicly accessible variables. Use set/get instead. (Yes, I know it
> is slower, but - you can inline it, and the object is notified if
> someone changes the variable. Also more flexible about storage of the
> variable.)

Hmmm not sure I entirely agree here. Sometimes represinting Pure Data 
Objects as public structs seems clearer to me but I do get your purist 
ideology here. One thing to remember is that if someone changes a 
variable then the corresponding get/set method suddenly has a deprecated 
return type/parameter (in many cases) and the ideal strived for becomes 
lost.

>
> Those are my eccentricities/coding style. Feel free to argue against -
> but be sure to rationalise. We're aiming for code readability, not
> file size or character count or anything concrete like that.
>
Regards,

- Galik