C++ coding guidelines

Discussion of chess software programming and technical issues.

Moderator: Ras

lucasart
Posts: 3243
Joined: Mon May 31, 2010 1:29 pm
Full name: lucasart

C++ coding guidelines

Post by lucasart »

I'm looking for good C++ coding guidelines to follow. Suggestions welcome.

In particular, because C++ is so complex, and there are so many different ways of doing the same thing in C++, my project is getting a bit messy, and the coding style lacks consistency.

Also, I need to make the code more self explanatory, by using self-obvious and consistent naming conventions (so it can be understood w/o comments, although additional comments are always good).

Or if you're interested to have a look at the actual code, and have some coding style suggestions:

Code: Select all

https://github.com/lucasart/chess.git
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
mar
Posts: 2672
Joined: Fri Nov 26, 2010 2:00 pm
Location: Czech Republic
Full name: Martin Sedlak

Re: C++ coding guidelines

Post by mar »

Forget about C++, it's flawed: http://yosefk.com/c++fqa/defective.html
ZirconiumX
Posts: 1361
Joined: Sun Jul 17, 2011 11:14 am
Full name: Hannah Ravensloft

Re: C++ coding guidelines

Post by ZirconiumX »

In My Stupid Opinion, maybe you could try to generate your own magics, or at least encapsulate the magic code in a class.

Matthew:out
tu ne cede malis, sed contra audentior ito
abulmo
Posts: 151
Joined: Thu Nov 12, 2009 6:31 pm

Re: C++ coding guidelines

Post by abulmo »

mar wrote:Forget about C++, it's flawed: http://yosefk.com/c++fqa/defective.html
Yes, but what else?

C is not an answer as C++ is a "better C".
Other languages all produce inefficient binary, and so are not good alternatives either.
Richard
mar
Posts: 2672
Joined: Fri Nov 26, 2010 2:00 pm
Location: Czech Republic
Full name: Martin Sedlak

Re: C++ coding guidelines

Post by mar »

abulmo wrote: Yes, but what else?

C is not an answer as C++ is a "better C".
Other languages all produce inefficient binary, and so are not good alternatives either.
No that was a joke (Lucas will understand), I forgot to include a smiley.
As for alternatives: there's D: http://dlang.org/index.html, written and designed by Walter Bright.
Here's a talk about static ifs (borrowed from D): http://channel9.msdn.com/Events/GoingNa ... d-a-Hammer
D isn't very popular unfortunately.
kinderchocolate
Posts: 454
Joined: Mon Nov 01, 2010 6:55 am
Full name: Ted Wong

Re: C++ coding guidelines

Post by kinderchocolate »

Why not try "Coding Complete"? If you abstract your concepts correctly, your project should be more manageable. My own project has over 200 C++ files, but I've found no problems.

lucasart wrote:I'm looking for good C++ coding guidelines to follow. Suggestions welcome.

In particular, because C++ is so complex, and there are so many different ways of doing the same thing in C++, my project is getting a bit messy, and the coding style lacks consistency.

Also, I need to make the code more self explanatory, by using self-obvious and consistent naming conventions (so it can be understood w/o comments, although additional comments are always good).

Or if you're interested to have a look at the actual code, and have some coding style suggestions:

Code: Select all

https://github.com/lucasart/chess.git
lucasart
Posts: 3243
Joined: Mon May 31, 2010 1:29 pm
Full name: lucasart

Re: C++ coding guidelines

Post by lucasart »

ZirconiumX wrote:In My Stupid Opinion, maybe you could try to generate your own magics, or at least encapsulate the magic code in a class.

Matthew:out
I don't think class encapsulation is relevant in this particular case. Magic bitboards have a functional reality, not an object reality. Basically you have precomputed arrays, and 2 functions (bishop_attack and rook_attack). Encapsulating into a class is conceptually wrong, because an instance of that class doesn't make any sense. Why would I ever want to instantiate several Magic objects ? IMO the right way to encapsulate such things is to use a namespace, not a class.

This misconception (that everything should be encapsulated into a class) typically emanates from Java programmer.

As for generating my own magics, I really don't want to spend my time reinventing the wheel. I have enough things to do before I get something decent (comparable to Ilari's brillant cutechess-cli).

But yes, you have a fair point about encapsulation in general (class or namespace). I need to think about createing some (well chosen) namespaces.
Last edited by lucasart on Sun Oct 21, 2012 1:18 pm, edited 1 time in total.
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
User avatar
ilari
Posts: 750
Joined: Mon Mar 27, 2006 7:45 pm
Location: Finland

Re: C++ coding guidelines

Post by ilari »

Google's C++ style guide is pretty good, and has good reasoning behind every rule.

One suggestion for your project's design would be to use composition instead of inheritance between the Engine and Process classes, ie. Engine should have a private member variable of type Process. That's how it's implemented in Cute Chess - the ChessEngine class has a QIODevice member which could be a process, a TCP socket, a file, etc.
mcostalba
Posts: 2684
Joined: Sat Jun 14, 2008 9:17 pm

Re: C++ coding guidelines

Post by mcostalba »

lucasart wrote: Also, I need to make the code more self explanatory, by using self-obvious and consistent naming conventions
Naming is one of the most difficult thing to get it right, of course it is not related to C++ but it is common for any language. It requires a lot of "sensibility" and a lot of clearness of mind: if you know exactly what you are doing your naming will be better than if you have a more or less focused idea or don't understand completely the subject.

It may be a coincidence (I think it isn't), but I have found, reading the sources of various engines, that the best picked up names (that I have shameless adapted to SF) come from the best engines, written by the best developers.

I can suggest this for the principles behind consistent naming:

http://doc.qt.digia.com/qq/qq13-apis.html
lucasart
Posts: 3243
Joined: Mon May 31, 2010 1:29 pm
Full name: lucasart

Re: C++ coding guidelines

Post by lucasart »

ilari wrote:Google's C++ style guide is pretty good, and has good reasoning behind every rule.

One suggestion for your project's design would be to use composition instead of inheritance between the Engine and Process classes, ie. Engine should have a private member variable of type Process. That's how it's implemented in Cute Chess - the ChessEngine class has a QIODevice member which could be a process, a TCP socket, a file, etc.
Thank you Ilari. I will have a look at your link.

My rationale for the process base class, was that it has no dependancies, and can be extracted as is, and used in any other project that needs to spawn/kill child processes, and "talk" to them via stdin/stdout.

The most important thing for me is to find a good way to name my variables/class/functions. There is already a lot of inconsistency there, and I haven't found a systematic way of naming things :oops:
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.