   | |  | | ![]() Since we are using C++ and since it is very easy to shoot yourself in the foot with C++. I recommend that we using these coding guidelines. These are in addition to using code formatting using astyle.
- Use the STL.
- Use <tt>using namespace std;</tt>
- Use <tt>std::stringstream</tt>
- For STL containers, Use <tt>std::vector<SomeStruct></tt> for structures and <tt>std::vector<SomeClass *></tt> for classes.
- Avoid the C standard library.
<tt>#include <stdio.h> or #include <cstdio>
#include <stdlib.h> or #include <cstdlib></tt>
There is one exception: <cmath> - Avoid globals.
Use member variables, static members, and this:
<tt>bool someTesterFunction()
{
static int state = -1; // Use static fields
// like this to avoid globals.
if (state == -1)
{
bool result = false;
// compute result.
state = result ? 1 : 0;
}
return state == 1;
}</tt> - Avoid allocating memory yourself. If you do allocate memory yourself, make sure you have clean up code.
- Avoid initializing complex constructors in the class constructor initializer.
<tt>class A
{
public:
A(int j, int k, int l);
};
class B
{
A a;
A a2;
public:
B() :
a(1,2,3), // Avoid this.
a2(NULL)
{
a2 = new A(1,2,3); // Do this.
}
~B()
{
if (a2 != NULL) delete a2;
a2 = NULL;
}
};</tt> - All names should follow Java style.
Variables/Functions: int fooBar, void bazFoo()
Classes/Structures: SomeClass
No prefixing. - Avoid performing unnecessary operations in for(), while(), or if() conditions.
i.e.
<tt>float a = 1;
while ((a *= 2.7 * a - a) < 328);
if ((a *= .91 - a) > someValue) a = 0;</tt> - Avoid nesting ? : conditionals (even if you use parentheses).
i.e.
<tt>float a = test1 ? test2 ? 1 : 2 : 3;
// or
float a = !test1 ? 3 : test2 ? 1 : 2;</tt> - Avoid putting whitespace for formatting in the middle of a line.
- Avoid putting <tt>void</tt> for a method with no arguments.
- Use Java's @style meta-comments in documents. (See: Doxygen)
Also:
<tt>/**
* Write comments like this.
*/</tt> - Take full advantage of Doxygen's ability to document members. By using a brief comment after the member.
- Avoid code that generates warnings during compilation, preferably warningless on other compilers. The code should be able to be built with -Werror -Wall (gcc), -we -Wall (msvc), or equivalent for your compiler.
- Sanity check liberally. In keeping with Guidline #5, avoid using assert().
Along the lines of:
<tt>int get_something(int index)
{
if (0 < index || index >= cur_size)
throw std::out_of_range("index is out of range");
return something[index];
}</tt>
Wrapping the sanity checks in a macro & useful error format TBD.
Of course, this is all subject to debate. There are also probably more. I just recommend these because I find that they allow fast, readable code to be developed.
Also, please note, I say "avoid", not "don't use", because there are some cases where violating the coding guidelines is better. Like for example 8, if A was a structure instead of a class, it is usually better to initialize it in the constructor initializer. | |  | |  |
|
└> last changed by Hello! :) on April 05, 2008 at 03:54
|
| written by Puck on Mar 10, 2008 17:46 |
 | |  | | ![]() I do basically all of those things anyway*, but there's one thing I should mention: using namespace std; breaks Irrlicht, since it defines some classes with the same names as STL containers. I probably wouldn't even mention it except that Irrlicht seems to be the popular choice for graphics engine, so it may be worth reconsidering. 
* I always use stdio.h, but only because MingW has an annoying issue where iostream adds about 500KB to the executable size. GCC on linux doesn't have that issue. | |  | |  |
|
 | |  | | ![]()  | Puck said: | | I do basically all of those things anyway*, |
But it still is a good idea to have it in writing.
| Puck said: | | but there's one thing I should mention: using namespace std; breaks Irrlicht, since it defines some classes with the same names as STL containers. I probably wouldn't even mention it except that Irrlicht seems to be the popular choice for graphics engine, so it may be worth reconsidering. |
Fixable by requiring that Irrlicht's containers be used when Irrlicht has an appropriate container.
| Puck said: | | * I always use stdio.h, but only because MingW has an annoying issue where iostream adds about 500KB to the executable size. GCC on linux doesn't have that issue. |
But we don't have to use MinGW for Windows. 
Also, have you tried the -s linker flag (gcc: -Wl,-s) to strip unnecessary code? | |  | |  |
|
| written by Puck on Mar 10, 2008 19:47 |
| | | | ![]() | Hello! said: | | But it still is a good idea to have it in writing. |
Indeed, what I meant was more "I do pretty much all that anyway, so it's perfectly agreeable to me."
| Hello! said: | | Fixable by requiring that Irrlicht's containers be used when Irrlicht has an appropriate container. |
Possibly, but unfortunately they're part of irr::core. I personally find that I use the irr::core classes much more than the STL std classes, since it includes things like vectors, matrices, 2d positions and so on in addition to the mentioned containers. With STL you usually only have to use the std:: namespace when declaring the container variables.
| Hello! said: | | Also, have you tried the -s linker flag (gcc: -Wl,-s) to strip unnecessary code? |
Indeed I have, but unfortunately it doesn't seem to make any difference.  Anyway, it was only a sidenote. Of course no one has to use MingW, but I personally prefer it. 500KB isn't that much anyway. | | | | |
|
| sun + black hole = fwoosh! |
|
  | |  | | ![]() I don't know much about the STL (having never used it, c++ templates, or c++ namespaces - if I needed a resizable list in c++, I made it myself).
If Irrlicht has classes that do what we need, why not use those instead so we don't have to mess with getting stlport and getting it set up?
I've never liked iostream, and strongly prefer to use printf/sprintf/etc instead. (One reason is that I can never remember whether >> is input or output, and that >> and << are supposed to be bitshift operators, not bizarre output/input-to/from-stream operators)
I'd like to know why you think stdio and stdlib shouldn't be used.
(I have no problems with avoiding globals, and I presume stringstream is an alternative to using char* for strings?)
What does being on a 64-bit platform mean you would have to do differently? (Or, what would we need that isRunning64Bit function for?)
(I'm rather used to not having to care whether the platform is 32-bit or 64-bit, because the libraries work the same regardless, and you don't need to do anything special, and the integer types are always the same length regardless of platform (in c# or java), AFAIK)
I'd suggest a couple other things:
9. Always include the {}s on an if statement, while, etc. If they're missing, there's a tendency to not notice they're missing, add some more lines that are tabbed over with the other line, and then things break. Adding the {} only adds one extra line if your {s are on the same line as your if/while/etc.
(And I'd suggest one about where the {}s should be, but I bet everyone disagrees about it, and will want to do anything they write in whatever their favorite way is)
We should probably pick a standard way to capitalize things - For instance, SomeClass, SomeMethod(), someVariable, SOME_CONSTANT, etc, and stick to that.
I'd say that annoying prefixes (m_wtfFoobar) on variable names (instead of foobar) should not be used, either - they just give you a headache when you (a) have to change all the references to the variable if you change its type, or (b) you don't change them and the prefix becomes misleading, and (c) you don't know what the hell they mean anyways. If you're using an IDE you can just hover the mouse over the variable name to see what type it is anyhow. | |  | |  |
|
 | |  | | ![]() | Shadowlord said: | | If Irrlicht has classes that do what we need, why not use those instead so we don't have to mess with getting stlport and getting it set up? |
Actually, I would not use STLport even if my life depended on it. Irrlicht only has equatable: string, list, map, and vector containers.
| Shadowlord said: | I've never liked iostream, and strongly prefer to use printf/sprintf/etc instead. (One reason is that I can never remember whether >> is input or output, and that >> and << are supposed to be bitshift operators, not bizarre output/input-to/from-stream operators)
> |
I never liked sprintf() due to having to figure out what my upper bound of how many bytes I'd need to write would be (without wasting memory). It does make some formatting easy though.
| Shadowlord said: | | I'd like to know why you think stdio and stdlib shouldn't be used. |
Global pollution? Neither really have any useful functions, except perhaps for sprintf()/vsprintf().
| Shadowlord said: | | (I have no problems with avoiding globals, and I presume stringstream is an alternative to using char* for strings?) |
Actually, std::stringstream is the std::string alternative to sprintf. However, if we do use irr::core::string, we wouldn't be able to use std::stringstream (unless we use a custom streambuf, which isn't so hard).
| Shadowlord said: | What does being on a 64-bit platform mean you would have to do differently? (Or, what would we need that isRunning64Bit function for?)
(I'm rather used to not having to care whether the platform is 32-bit or 64-bit, because the libraries work the same regardless, and you don't need to do anything special, and the integer types are always the same length regardless of platform (in c# or java), AFAIK) |
I forgot to mark the line using the static variable. Basically I just made it the variable very scope specific, to avoid globals. The entire function was used as an example to show a static variable within the function avoided using the global scope.
You shouldn't have to worry about 64-bit. I can have fun figuring out why some code doesn't work in 64-bit.
| Shadowlord said: | I'd suggest a couple other things:
9. Always include the {}s on an if statement, while, etc. If they're missing, there's a tendency to not notice they're missing, add some more lines that are tabbed over with the other line, and then things break. Adding the {} only adds one extra line if your {s are on the same line as your if/while/etc.
(And I'd suggest one about where the {}s should be, but I bet everyone disagrees about it, and will want to do anything they write in whatever their favorite way is) |
Forgot about that. Though part of this would be covered using Artistic Style formatting. I'll add the {} part though.
| Shadowlord said: | We should probably pick a standard way to capitalize things - For instance, SomeClass, SomeMethod(), someVariable, SOME_CONSTANT, etc, and stick to that.
I'd say that annoying prefixes (m_wtfFoobar) on variable names (instead of foobar) should not be used, either - they just give you a headache when you (a) have to change all the references to the variable if you change its type, or (b) you don't change them and the prefix becomes misleading, and (c) you don't know what the hell they mean anyways. If you're using an IDE you can just hover the mouse over the variable name to see what type it is anyhow. |
Forgot about that. So Java-style variable selection? | |  | |  |
|
 | |  | | ![]() Added 11 & 12. Basically related to conditionals. | |  | |  |
|
| sun + black hole = fwoosh! |
|
| | | | ![]() About capitalization, I prefer the slightly different C# style, which is the same as the java style except that method names and properties (getter/setter things) have their first letter capitalized (to more easily distinguish them from variables) - but I don't mind the difference too much.
Of course that can lead to weirdness like having:
| | public class Zort {
private FooBar fooBar;
public FooBar FooBar { get { return fooBar; } }
} |
| | | | | Yes, you really can have a property whose name is the same as another class's name in C# (or even the same class's name). 
The main advantage: You can't do this with the java style:
| | public class Zort {
private FooBar fooBar;
public FooBar fooBar { get { return fooBar; } }
} |
| | | | | (I'm not sure if c++ minds if you have methods with the same name as member variables) | | | | |
|
 | | | | ![]() I'd agree with most of what you say, except perhaps for:
- Using { } on single-line statements: personally I find that an over-do.
- Stdio.h might be useful for basic error reporting on the main program, or for log file writing during error recovery. Other than that, and perhaps some sprintf(), I don't think in general we'll be really doing much file IO as for worrying about that.
Edit: Oh, another thing: we really should agree on a tab size. 4 or 8 (but preferably not 3 ot 5). Personally I use 8, but I'm willing to adapt. | | | | |
|
| written by Bensel on Mar 11, 2008 03:14 |
| | | | Or we could just use actual tabs and let people's editors make it look however they want it to. | | | | |
|
| | | | ![]() That's exactly what I mean, use always tabs, but agree on which size the editor think a tab is. | | | | |
|
 | |  | | ![]() Just a quick question, does anyone do coding in a 80x25 terminal window? If there are, you suck : P and it wouldn't be good to have a tab size of 8. I personally use a tab size of 2 (and convert tabs to spaces), along with an 7/8pt font. Screen realestate is quite valuable, the more code I can see the better.
Edit: I don't really like C#'s naming conventions. It means an extra keypress (shift). | |  | |  |
|
| sun + black hole = fwoosh! |
|
| | | | ![]() | Barebones said: | | That's exactly what I mean, use always tabs, but agree on which size the editor think a tab is. |
It should be irrelevant if everyone uses tabs and not spaces. They'll look like tabs are 4 spaces to me, and look like they're 8 spaces to you, etc. Some people use 3 spaces or other weird things, but it really doesn't matter unless someone isn't using actual tabs (or unless their editor is replacing them with spaces, which some do... but you should be able to turn that off).
Edit:
| Hello! said: | | Edit: I don't really like C#'s naming conventions. It means an extra keypress (shift). |
That's ... strange. Pressing Shift Doesn't Add Any Time To What I'm Typing, Doesn't Really Slow Me Down At All. I'm Just Hitting It With My Left Pinky While Typing Normally (Unless I Have To Type An A, In Which Case I'm Pressing The A With The Next Finger Over While Still Holding Shift With My Pinky).
If it's adding any time it all, it isn't more than a tenth of a second or so per capital letter. | | | | |
|
| | | | ![]() | Shadowlord said: | | They'll look like tabs are 4 spaces to me, and look like they're 8 spaces to you, etc. |
Here you have an example of what I mean. Imagine this file when shared among people that view tabs differently:
| | class Planet {
Vector position; // relative to galaxy center
double now, elapsed; // time
unsigned int seed, prev; // for the random generator
unsigned int shuffle[2];
... |
|
|
| sun + black hole = fwoosh! |
|
| | | | ![]() | Barebones said: | | Here you have an example of what I mean. Imagine this file when shared among people that view tabs differently: |
| | class Planet {
Vector position; // relative to galaxy center
double now, elapsed; // time
unsigned int seed, prev; // for the random generator
unsigned int shuffle[2];
... |
| | | | | </q>
I would say: Don't do that . Tabs should only be used to the left of text, never in between text.
Edit: Eew, the code block broke the quote. | | | | |
|
|
