Latest revision as of 18:56, 5 November 2009

is/has-convention

bjm: Using the is/has convention for booleans allows writing code that reads like natural english:

if(m_isFileOpen && m_aSource.hasData() && their_isLoggingEnabled) lcl_writeLogEntry();

"If my file is open and my source has data and the logging for all SomeClass is enabled then write a log entry." an alternative would be our_ as prefix for static members.

if(m_isFileOpen && m_aSource.hasData() && our_isLoggingEnabled) lcl_writeLogEntry();

"If my file is open and my source has data and our logging is enabled then write a log entry."

hungarian prefixes

tl: Use the "a" prefix for class/struct values (not primitives like int, float, char, bool, ...) only.

bjm: Why not for primitives? Keep in mind there are still the optional prefixes.

For primitives (aka POD types) there are n for unsigned/int/long, f for double (hopefully float is not used ...), c for char and b for bool. Using a with those is just confusing and should be reserved for class object instances and similar. --erAck 14:28, 9 October 2008 (CEST)

anonymnous namespace

mst: imho anonymous namespaces in c++ are completely useless; just use static linkage instead

bjm: why not both? That might at least help code analysis tools like lxr, autodoc, doxygen etc.

thb: they are far from useless, but they usually don't do the same as static linkage (namely, they are still external for the linker)

virtual inheritance

thb: does this capture the intention?

bjm: There are good points in that one. Consider the following example: You have defined these public interfaces:

struct INamed
{
    virtual ::std::string getName() =0;
};

struct IFancyInterface
    : virtual INamed
{
    virtual void doSomeFancyStuff() =0;
};

struct ICoolInterface
    : virtual INamed
{
    virtual void doSomeCoolStuff() =0;
};

INamed is a very basic interface and gets reused in a lot of other interfaces - that is not a Bad Thing(tm) as an interface carries no state, just guarantees of accepted messages. Also all these interfaces are very public (used by other modules, used in an external API), thus they should not be touched. Now you want to implement a class exposing both the IFancyInterface and the ICoolInterface.

class FancyAndCoolPerson
    : IFancyInterface
    , ICoolInterface
{
    public:
    virtual void doSomeFancyStuff()
    {
        ::std::cout << "Im fancy, and my name is " << getName() << ::std::endl;
    };

    virtual void doSomeCoolStuff()
    {
        ::std::cout << "Im cool, and my name is " << getName() << ::std::endl;
    };

    virtual ::std::string getName()
        { return "Mary"; };
};

If one of the interfaces wouldnt use virtual inheritance this wouldnt be possible.