Angeleon Askaroth
05-22-2007, 11:16 AM
Code structure:
* intendation should be three whitespaces per step. The use of tab is not preferred as it varies between editor.
* Wherever it is applicable, the { should be on the row directly below its owner.
* if there are a lot of intendations in a code, consider writing a subfuction to replace them.
* Avoid longer functions. Should it seem to get out of hand, write a subfunction to handle some of the rows.
Functions:
* the first word should start with a lower-case letter, but the remaining words should have the first letter upper-case. I.E: aGoodName();
Classes:
* the names of classes has the same structure as functions, except it also starts with a upper-case. ThisIsGoodClass
* Get and Set functions should be the standard for accessing variables. Making them inline is also a good habit(might not make any real difference, but the effort isn't big anyway).
* all the membervariables will begin with a m (for member) followed by a underscore. then start the first word with a lowercase while the following are upper-case. m_goodNameThisIs;
* all memberfunctions should be started with a small letter in the first words followed by uppercase first letters of the rest of the words: functionOne()
* Const functions should be used if possible.
* { should be under the class name.
* public, private and protected should be at the same level as the { for the class.
* Get and Set functions can be fully withing the class definition, but otherwise functions should be defined in a seperate file.
Documentation:
* Every class-definition file (.h) should have a document header explaining what the class does and any important information. First thing in the file.
* Every functions should have a simple one-line comment that will explain it briefly.
* Use english (obviously.;))
* Rule of thumb: Comment one line for every for, switch or while-loop and when there's something advanced or cryptic.
-----------------------------------------------------------------
Example (Foo.h)
-----------------------------------------------------------------
/*
* Filename: foo.h
* History:
* pA1 2004-02-23 Benny Created
* pA2 2004-02-25 Leo Added func.
* A 2004-02-26 Daniel Completed
*
* Foo creates a virtual puppy that you can kick at will
* with the function kickPuppy(int x) where x should not
* be four becuase then it will eat you.
* It will handle the graphics and physics of the puppy,
* but the sounds is not handled in this class. It will
* call a class to handle that.
*
* Oh, and it calculates string Theory.
*
*/
#ifndef FOO_H
#define FOO_H
class Foo
{
public:
// Constructor that creates the object.
Foo();
// The destructor
virtual ~Foo();
// Performs string theory math.
int bar();
// Performs even more string theory math.
int barImproved();
};
#endif
-----------------------------------------------------------------
Example (Foo.cpp)
-----------------------------------------------------------------
#include "foo.h"
int Foo::bar()
{
if ( 6 > 7 )
{
return 0;
}
else
{
return 1;
}
}
Foo::Foo()
{}
Foo::~Foo()
{}
int Foo::barImproved()
{
return ( 1 * 1 );
}
Alright. This sounds like a good start right? Any comments or preferences that I should take into consideration? Personally, this is what I've been using for a while, but I've always been flexible so changing anything or all of it isn't a big deal. Besides, no one will kill you for not following it properly. =)
I'm not big on commenting, I always find that you can spend the time better on other things. Like sleeping, so there's no need to do anything more than basic commenting like I mentioned above.
Anything else?
* intendation should be three whitespaces per step. The use of tab is not preferred as it varies between editor.
* Wherever it is applicable, the { should be on the row directly below its owner.
* if there are a lot of intendations in a code, consider writing a subfuction to replace them.
* Avoid longer functions. Should it seem to get out of hand, write a subfunction to handle some of the rows.
Functions:
* the first word should start with a lower-case letter, but the remaining words should have the first letter upper-case. I.E: aGoodName();
Classes:
* the names of classes has the same structure as functions, except it also starts with a upper-case. ThisIsGoodClass
* Get and Set functions should be the standard for accessing variables. Making them inline is also a good habit(might not make any real difference, but the effort isn't big anyway).
* all the membervariables will begin with a m (for member) followed by a underscore. then start the first word with a lowercase while the following are upper-case. m_goodNameThisIs;
* all memberfunctions should be started with a small letter in the first words followed by uppercase first letters of the rest of the words: functionOne()
* Const functions should be used if possible.
* { should be under the class name.
* public, private and protected should be at the same level as the { for the class.
* Get and Set functions can be fully withing the class definition, but otherwise functions should be defined in a seperate file.
Documentation:
* Every class-definition file (.h) should have a document header explaining what the class does and any important information. First thing in the file.
* Every functions should have a simple one-line comment that will explain it briefly.
* Use english (obviously.;))
* Rule of thumb: Comment one line for every for, switch or while-loop and when there's something advanced or cryptic.
-----------------------------------------------------------------
Example (Foo.h)
-----------------------------------------------------------------
/*
* Filename: foo.h
* History:
* pA1 2004-02-23 Benny Created
* pA2 2004-02-25 Leo Added func.
* A 2004-02-26 Daniel Completed
*
* Foo creates a virtual puppy that you can kick at will
* with the function kickPuppy(int x) where x should not
* be four becuase then it will eat you.
* It will handle the graphics and physics of the puppy,
* but the sounds is not handled in this class. It will
* call a class to handle that.
*
* Oh, and it calculates string Theory.
*
*/
#ifndef FOO_H
#define FOO_H
class Foo
{
public:
// Constructor that creates the object.
Foo();
// The destructor
virtual ~Foo();
// Performs string theory math.
int bar();
// Performs even more string theory math.
int barImproved();
};
#endif
-----------------------------------------------------------------
Example (Foo.cpp)
-----------------------------------------------------------------
#include "foo.h"
int Foo::bar()
{
if ( 6 > 7 )
{
return 0;
}
else
{
return 1;
}
}
Foo::Foo()
{}
Foo::~Foo()
{}
int Foo::barImproved()
{
return ( 1 * 1 );
}
Alright. This sounds like a good start right? Any comments or preferences that I should take into consideration? Personally, this is what I've been using for a while, but I've always been flexible so changing anything or all of it isn't a big deal. Besides, no one will kill you for not following it properly. =)
I'm not big on commenting, I always find that you can spend the time better on other things. Like sleeping, so there's no need to do anything more than basic commenting like I mentioned above.
Anything else?