Summary of C++ Coding Guidelines

[Vic]

The purpose of this document is to define one style of programming in C++. The guidelines presented here are not final, but should serve as a basis for continued work with C++. This collection of guidelines should be seen as a dynamic document; suggestions for improvements are encouraged.Author: Vic P.
Contact: vic4key[at]gmail.comPDF Link

http://1drv.ms/1NAI0ll

 

[Conquest]

Also refer to this for some interesting observations from the creators - 

 

https://isocpp.org/faq

[mrexodia]

Hello,You should include code samples for everything that is too complicated to understand in 2 seconds."Braces ("{}") that enclose a block are to be placed in the same column, on separate lines directly before and after the block."What does this mean?

if (condition) {    ; //statement}//orif (condition){    ; //statement}

Samples illustrate this far better than any amount of words."A long name is normally better than a short, cryptic name, but avoid overly long names, as these become tedious with repetition."Define overly long, some people think a 5 character name is long for their variables, but other people have no problems with 20+ characters."Do not use names that begin with anything other than alpha characters."Is underscore an 'alpha character'? Is the muscled male emoji an 'alpha character'?"Names should not include abbreviations that are not generally accepted."Same here, it is very ambiguous what 'generally accepted' means here. Is it generally accepted by any person speaking English or any person in the domain you are programming in?"Structs should not be used as they contain only public data."It's simply not true: http://codepad.org/O3gwlO7J"Friends of a class should be used to provide additional functions that are best kept outside of the class."
"Friends are good if used properly. However, the use of many friends can indicate that the modularity of the system is poor."This is kind of contradictory, just don't allow friend for everybody's sake."Avoid explicit type conversions from a const type to a non-const type."I think this should not be under the Const Member Functions heading as it is about types, not about const member functions "All classes that are used as base classes and that have virtual functions, must define a virtual destructor."Google for "virtual destructor dangerous" there is a lot of dangerous shit with virtual destructors going on (undefined behavior). I'm no expert on this just think you should look at it."Do not call virtual function in a constructor."What about virtual functions used by an interface that is passed as an argument to the constructor (for example to initialize hardware)? Is this all virtual functions or just the ones in your class because I think that's undefined behavior (again not sure)."An assignment operator ought to return a const reference to the assigning object."Why?"A public member function must never return a non-const reference or pointer to member data."Just not return pointers to member data? This always leads to bugs where there is a pointer to deallocated member data hanging around in unknown places in your code."Function arguments that are passed by pointer or reference should be declared as const unless:"Unless the function modifies them??I could go on for a little while, but in general this guide needs more reasoning for your (sometimes very good) rules. Apart from that it also needs code examples. Anothing thing is about the context of this guide. Could you provide us with who uses this (for example your company internally) and what kind of field you work in. I think this helps people decide whether this guide is for them.I hope this helps you with your guide further as the idea is good.Mr. eXoDiaPS Something that might interest you:

https://www.youtube.com/watch?v=1OEu9C51K2A

 

https://github.com/isocpp/CppCoreGuidelines (something like you did but then far broader).

Edited November 19, 2015 by Mr. eXoDia

[atom0s]

In the end, a lot of things that are covered in this document are entirely opinion based and personal preference. The C++ standard allows for flexible syntax on various things that a lot of documents like this one try to teach incorrectly. The example Mr. eXodia pointed out with braces is a great example. Some will argue that having the opening brace on the same line as the statement is "proper", while others will say having it on its own line is. Either way, it works and is accepted by the language standard so trying to force people into one method or the other is making it worse.

[Vic]

Hello Mr. eXodia,

Hi atom0s,

 

Sorry for slow reply. I was so busy in the last of the year. Now I got free time to visit our forum. The interface changed. It's very beautiful.

I will reply all of your comments in below:

 

Quote

Braces ("{}") that enclose a block are to be placed in the same column, on separate lines directly before and after the block."What does this mean?

Ex.

{ // the same column. In this ex is col 0
	// Your code here
	// on separate lines directly
	// before and after the block
}

 

 

Quote

Samples illustrate this far better than any amount of words."A long name is normally better than a short, cryptic name, but avoid overly long names, as these become tedious with repetition."Define overly long, some people think a 5 character name is long for their variables, but other people have no problems with 20+ characters.

Ex. I have a function:

void termThread()

Terminate Thread or Terminal Thread??

 

 

Quote

"Do not use names that begin with anything other than alpha characters."Is underscore an 'alpha character'? Is the muscled male emoji an 'alpha character'? Names should not include abbreviations that are not generally accepted. Is it generally accepted by any person speaking English or any person in the domain you are programming in?

It's a recommended and not "can not". Everything is "should".

 

 

Quote

"Friends of a class should be used to provide additional functions that are best kept outside of the class"

Suppose there is a list class that needs a pointer to an internal list element in order to iterate through the class. This pointer is not needed for other operations on the list. There may then be reason, such as obtaining smaller list objects, for an list object not to store a pointer to the current list element and instead to create an iterator, containing such a pointer, when it is needed. One problem with this solution is that the iterator class normally does not have access to the data structures that are used to represent the list (since we also recommend private member data). By declaring the iterator class as a friend, this problem is avoided without violating data encapsulation.

 

 

Quote

"Friends are good if used properly. However, the use of many friends can indicate that the modularity of the system is poor."This is kind of contradictory, just don't allow friend for everybody's sake.

Suppose there is a list class which needs a pointer to an internal list element in order to iterate through the class. This pointer is not needed for other operations on the list. There may then be reason, such as obtaining smaller list objects, for an list object not to store a pointer to the current list element and instead to create an iterator, containing such a pointer, when it is needed.

 

 

Quote

All classes that are used as base classes and that have virtual functions, must define a virtual destructor."Google for "virtual destructor dangerous" there is a lot of dangerous shit with virtual destructors going on (undefined behavior). I'm no expert on this just think you should look at it.

We have an example. Lets first see what happens when we do not have a virtual CBase class destructor.

--- Non Virtual Destructor ---

class CBase {
	public:
	~Base() { cout << "CBase Destructor\t"; }
};

class CDerived: public CBase {
	public:
	~Derived() {cout<< "CDerived Destructor"; }
};

int main()
{
	CBase* obj = new CDerived;
	Cdelete obj;
}

Output :
CBase Destructor

--- Virtual Destructor ---

class CBase {
	public:
	virtual ~Base() { cout << "CBase Destructor\t"; }
};

class CDerived: public CBase {
	public:
	~Derived() { cout<< "CDerived Destructor"; }
};

int main()
{
	CBase* obj = new CDerived;
	Cdelete obj;
}

Output :
CDerived Destructor
CBase Destructor

 

Quote

"Do not call virtual function in a constructor."What about virtual functions used by an interface that is passed as an argument to the constructor (for example to initialize hardware)? Is this all virtual functions or just the ones in your class because I think that's undefined behavior (again not sure).

Ex. You can visit this link: https://isocpp.org/wiki/faq/strange-inheritance#calling-virtuals-from-ctors

 

 

Quote

"An assignment operator ought to return a const reference to the assigning object."Why?

If an assignment operator returns “void”, then it is not possible to write a = b = c. It may then be tempting to program the assignment operator so that it returns a reference to the assigning object. Unfortunately, this kind of design can be difficult to understand. The statement (a = = c can mean that a or b is assigned the value of c before or after a is assigned the value of b. This type of code can be avoided by having the assignment operator return a const reference to the assigned object or to the assigning object. Since the returned object cannot be placed on the left side of an assignment, it makes no difference which of them is returned (that is, the code in the above example is no longer correct).
 

 

Quote

"A public member function must never return a non-const reference or pointer to member data."Just not return pointers to member data? This always leads to bugs where there is a pointer to deallocated member data hanging around in unknown places in your code.

Allow a user direct access to the private member data of an object, this data may be changed in ways not intended by the class designer.

 

 

Quote

Function arguments that are passed by pointer or reference should be declared as const unless:"Unless the function modifies them??

1. They are parameters to member access functions.
2. They are being passed with the specific purpose of being modified.

 

@Mr. eXodia: This document is not detailed because I wrote it for a summary document. Thanks for your comment, feedback and your attention.

@atom0s  I have known that. But in a company, a big project, teammate... We should create a standard style & a general style to make all the member of our company, our team,... follow to make easy to manage code.

Edited December 12, 2015 by Vic