Skip to content

Hacking conventions

Yohann Ferreira edited this page Oct 8, 2013 · 5 revisions

Rough draft taken from the blog, not to forget about it:

Here are the vital hacking rules:

  • Follow the camel casing already used in the code. (aka Cameleon coding)

variables: If they have a composed name, it is separated by a _. The private ones have _ in front of them, eg: _hello_buddy; They are lower-cased.

FunctionName(): They don't have a _ in their names. Each word start is upper-cased.

ect...

  • Ask before working on new features, you might be frustrated if it's not accepted after all the time you've spent on them. You'll be warned. ;)
  • Tabs are not accepted and will have to be changed to use 4 spaces instead.

Compilation time:

  • Implement in the header only for very simple function, like one-line getters. Remember that a header is compiled for every source file it is included in.

  • Never use: using namespace std; in new file, and remove them if you have the patience, since it's a very bad practice and is bad for the compile time.

  • Never include the big header such as video.h if you can only include image.h, for instance.

  • Never ever include <iostream> in a header. Only in the cpp file. You'll have to move the incriminated implementation in the source file as well.

  • Never include gl headers, or platform specific includes, like windows.h in headers. Most of the time, a better solution is existing.

  • Use one h/cpp file couple per class. This will help the compilation process and browsing the project. For now, many files don't follow that rule so please tend to go toward it by at least not adding more to the problem. ;)

Clone this wiki locally