What are good name conventions for classes. How for example should the name be different between a base class and a derived class or an abstract class and a concrete class?

Recommended Answers

All 4 Replies

There aren't really any "naming rules" per se. It's more a matter of common sense and personal preference. Many people will add a 'c' at the beginning of a class name to indicate that it's a class name. But, using bank accounts as a simple example, something like this would be perfectly fine:

class Account {  //an abstract base class
 protected:
   double balance;

 public:
   Account();
   virtual double withdraw(double) = 0; //pure virtual function
   virtual void deposit(double) = 0; //pure virtual function
};

class Savings : public Account { //"concrete" class, derived from Account
 public:
   Savings();
   double withdraw(double); //overridden function definition
   void deposit(double); //overridden function definition
};

class Checking : public Account { //"concrete" class, derived from Account
 public:
   Checking();
   double withdraw(double); //overridden function definition
   void deposit(double); //overridden function definition
};

To add to this, I will often not capitalize anything else in my program other than classes. And two word classes are multiple capitals (e.g., DogHouse, BankAccount, etc.)

int dogHouse   // variable
...

class DogHouse // class
...

dog_house()     // function
...

I have a tendency to not conform to this throughout my entire program though... which is something I personally need to start working on ><

I probably should have, but I didn't mention this before.

If you go to work for a corporation, there may be some rules regarding this. Many times, companies with programming departments will have "Corporate Standards" documents/procedures that dictate these types of things. If a company you go to work for does have a "standard" you will, obviously, have to adhere to that. But if there is no such document/procedure, who cares...

There is one naming convention that is used a bit and it's called Hungarian notation. I'm not sure of the exact format, but essentially it uses leading letters to indicates certain things, more or less like this:

class IAbstractClass { //notice "I" for abstract or interface or base classes.
  public:
    virtual void SomeMethod() = 0; //notice camel-back writing.
};
class CConcreteClass : public IAbstractClass { //notice "C" for class or concrete class.
  private:
    int mIntegerDataMember; //notice "m" for member, as in data member.
    IAbstractClass* pSomePointer; //notice "p" for pointer data member.
    IAbstractClass& rSomeRef; //notice "r" for some reference.
  public:
    void SomeMethod(); 
};

But this is an old naming convention that is now regarded as a bit retarded. Personally, I like the naming convention from the Boost libraries and the STD/STL libraries, but I used to loosely follow Hungarian notation so a lot of my code is a bit of a mix. What I try to follow now is more a _ separated words for classes, structs and other type names, and camel-back for data members and methods with first lower-case letter (or sometimes I use _ separated the data members too!), something like this:

class abstract_class { //notice all lower-case and _ separated.
  public:
    virtual void someMethod() = 0; //notice camel-back with lower-case start.
};
class concrete_class : public abstract_class { //notice no difference for concrete classes.
  private:
    int IntegerDataMember; //notice camel-back data member.
    abstract_class* SomePointer; //notice camel-back data member.
    abstract_class& SomeRef; //notice camel-back.
  public:
    void someMethod(); 
};

But like Fbody said, usually you adopt the one from where you are working at.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.