C++ coding standards - Include Files
We are going to be starting a new project at work this quarter. This is going to be a huge project with 4 developers working on it (2 of them full time). One thing we are trying to do is to come up with some coding guidelines so that the final product is consistent. I am in charge of putting together a list of these coding standards so that we can all agree on them. Here is the initial list that I came up for C++ Include files .
Guidelines
-
The name of the include file must match the name of the class.
- Car.h contains Car class
- Make an attempt to hide all private member variables and functions inside the d ptr. Your include file should only public interface.
-
The include file must not contain any implementation details of the d ptr of a class.
The only mention of the ‘d ptr’ should be as a private variable of the class and as a forward declaration. - Do not include any more files than you absolutely need. Make use of forward declarations as much as you can.
-
For access functions; use the ‘get()’ and ’set()’ naming notation.
- getBalance, setBalance, getName, setName etc.
-
Name of include guards should be all caps.
- #ifndef CAR_H
- The class hierarchy should be defined in terms of most accessible and least accessible functions.
- public
- protected
- private
So this is the 1st draft that I have put together. What do you guys think? Are there any that you disagree with? agree with? What are some that you use in your projects?
April 4th, 2006 in
Programming
Two more for the list:
- Make sure that the first .h included from a cpp is the .h with the same name (eg: book.cpp should include book.h in the first place. This will ensure you that book.h is including all the h needed).
- H files should never use using namespace XXX to avoid polluting other clients of the .H. Do it in the Cpp
My 0.02€
By the way, the d ptr, is the pimpl idiom isn’t it?
[...] A couple of days ago; I posted about some C++ coding guidelines. That post was mainly for some standards to keep in mind for header files. One thing that I mentioned in there was the use of a ‘d pointer’. It is also known as the Cheshire Cat implementation . The main idea here is to hide the implementation details from the user. The header file should only list the public interface; since that is the only interface the user is going to be using. Read more for a example of how to write a d ptr type implementation. This example will use a bank account object. Think of it as a Bank Savings account. There are two files: Account.h and Account.cpp. It is a common practice to name the d ptr as ‘ClassNamePrivate’. So in this case; it will be called AccountPrivate. [...]