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:
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:
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.
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.
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:
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
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
