Jump to content
XCOMUFO & Xenocide

Programming Convention


Timil

Recommended Posts

Sorry, it seem that the thread about documentation is flooded by divergent topic, so I repost my proposition here:

 

I only used the following source code style:

 

//

// Class:Method() - Description

// Programmer

// Additionnal description (dependancy or other non-directly related info)

Output Class::Method(input)

{

If

then

else

...

}

(each code level is separated by one more tabulation)

 

I always use constructor and destructor in my class definitions, it avoid some incoherency and the pb with recursive memory release in the ISO C++ compilator and result program. (a destructor, even empty, is enought to free the memory.. don't put it and you will have memory leak)

 

Notation convention:

TClassname -> Template class

CClassname -> Class (immediatly used)

p_name -> named pointer

P_name -> global named pointer

NAME -> global variable

- I_NAME

- UI_NAME

- ...

name -> local variable

- i_name

- ui_name

- ...

_name -> never used except in the rare preprocessed selfgenerated variable name (hard to code, and seldom do what you imagine.. and not really ISO supported, but acceptable as some program need them!)

 

Class are made independant as possible:

- Generic and totally independant classes are put in a project directory (and HD directory) called GC_libraryname (usually GC_LIB for Global Class, fun name isn't it?)

- Rule classes are placed in a directory names GC_Rule (have usually GC_LIB dependency, and call them with #include "../GC_LIB/tclassname.h" ). NO other dependency.

- Tool classes are placed in a directory names GC_Tool, same as above, and are only used in all program (exemple: File parser, time function, XML parser...)

- Graphical classes... never used any!

 

Any idea for the others classes?

Any thought about this example of project guideline?

Link to comment
Share on other sites

Guest stewart

How about using individual space for parsing level of code; tabs are too big, and spaces are good enough.

 

And I LOVE the Hungarian Notation like notation myself; could you define all examples of it.

Link to comment
Share on other sites

How about using individual space for parsing level of code; tabs are too big, and spaces are good enough.

 

And I LOVE the Hungarian Notation like notation myself; could you define all examples of it.

Just set you compiler tab to 4 spaces, the code looks really good and neat...

 

No comment on Hungarian Notation, i had casted my vote against it in other thread :uzzi:. The same for middle name underscores... (dont like it at all)...

Except for that theres some things in Timil style that are very useful... like always write down the constructor and destructor, we should add: "The destructor always virtual"... The T for templates its a good idea too. We should add I for general interfaces (abstract classes that define a behaivior instead of implement an object)...

 

For graphics classes check the engine documentation and you will find a lot of them to get an idea...

 

Greetings

Red Knight

Link to comment
Share on other sites

Guest stewart

I just hate the word wrap the occurs sooner by using tabs. I find individual spaces do the trick.

 

Maybe we need to look at the APIs for the various things that are being throw into this quilt. On the hand if we wrap everything then nevermind, I just figured maybe, say, CHrystal Space has some good conventions already.

Link to comment
Share on other sites

Guest stewart

When a line of text is longer than the window in which it is displayed the line continues on the next "virtual" line in the display window. Most apps that display text allow you to turn word wrap on or off. If you turn it off then you have to scroll over.

 

Whatever though, if you just can't live life without using tabs here, instead of spaces, then I won't make any bones about it.

Link to comment
Share on other sites

Sorry, it seem that the thread about documentation is flooded by divergent topic, so I repost my proposition here:

 

I only used the following source code style:

 

//

// Class:Method() - Description

// Programmer

// Additionnal description (dependancy or other non-directly related info)

Output Class::Method(input)

{

If

then

else

...

}

Hmm.. I was against this at first but maybe we should have a mailing list for things having to do with coding. Mainly because HTML does mess up the format.

 

ok about the method commenting here is somewhat what I usually do

 

// MethodName()

//

// Input:

// Output:

//

// Description:

 

There other fields that can be added like Note: and so forth as needed. I don't know if we need a programmer: thing for every method out there unless somebody really wants alot of credit. :) To me being listed in a seperate file as one of the programmers is good enough and then there is the Credits button in the game itself that would display all us programmers and 3d Modlers.

 

(each code level is separated by one more tabulation)

 

I always use constructor and destructor in my class definitions, it avoid some incoherency and the pb with recursive memory release in the ISO C++ compilator and result program. (a destructor, even empty, is enought to free the memory.. don't put it and you will have memory leak)

 

If you do that in the .cc file then that is what I do too. I like to keep the header file clean. Also in order to keep the main header file clean I only include the prototype for templates and inline methods there. If a main header file has an object that uses an inline or template then at the end of that file there would be something like

 

#include "xenocide/inline/Soldier.hh" or

#include "xenocide/template/Soldier.hh" (using "'s here because greather than is html code)

 

and in those file I will have the definition for the inline function or template function. If you haven't done this before it might take a bit getting used to on how to do with the templates but it is well worth it. That way your main header files stay clean and are easy to look at like the Java objects using javap.

 

Notation convention:

TClassname -> Template class

CClassname -> Class (immediatly used)

 

Ok I will be willing to do this. Just one question. Is it really that important to know which classes are normal classes and which are template classes? You usually can see that anyway since template classes use the greater and less than signs to initialize and the header file would clear that up too. In either case, if the rest of the group likes the above idea then I suggest removing the C from the front of regular class names.. Right now though I don't see the advantage.

 

p_name -> named pointer

P_name -> global named pointer

NAME -> global variable

- I_NAME

- UI_NAME

- ...

name -> local variable

- i_name

- ui_name

- ...

_name -> never used except in the rare preprocessed selfgenerated variable name (hard to code, and seldom do what you imagine.. and not really ISO supported, but acceptable as some program need them!)

 

Ok here I agree something needs to identify pointers. I usually have "namePTR" but if everyone else likes p_ that will work with me too. As for Global PTR's I don't know since I mostly only allow objects to be global. I don't like global variables that is for sure and I don't know if identifying local variables as local is that important.. I'm sure I've had global pointers before too.. I know global tables are ok.

 

Class are made independant as possible:

- Generic and totally independant classes are put in a project directory (and HD directory) called GC_libraryname (usually GC_LIB for Global Class, fun name isn't it?)

- Rule classes are placed in a directory names GC_Rule (have usually GC_LIB dependency, and call them with #include "../GC_LIB/tclassname.h" ). NO other dependency.

- Tool classes are placed in a directory names GC_Tool, same as above, and are only used in all program (exemple: File parser, time function, XML parser...)

- Graphical classes... never used any!

 

Any idea for the others classes?

Any thought about this example of project guideline?

 

In this project we won't rely as much on inheritances as usual to make the game more modable so yeah classes will be more independant. There still going to be some inheritances I'm sure especially if you believe in the model where all objects inherit from a root object.. I'm not so sure about your naming convention on the classes yet and would like a bit more time to think about it..

 

Hey btw everybody I'm back to work on the project as before and this time I got net access on linux too.. So I'll do CVS from here now instead of wincvs :)

Link to comment
Share on other sites

How about using individual space for parsing level of code; tabs are too big, and spaces are good enough.

 

And I LOVE the Hungarian Notation like notation myself; could you define all examples of it.

Just set you compiler tab to 4 spaces, the code looks really good and neat...

 

No comment on Hungarian Notation, i had casted my vote against it in other thread :uzzi:. The same for middle name underscores... (dont like it at all)...

Except for that theres some things in Timil style that are very useful... like always write down the constructor and destructor, we should add: "The destructor always virtual"... The T for templates its a good idea too. We should add I for general interfaces (abstract classes that define a behaivior instead of implement an object)...

 

For graphics classes check the engine documentation and you will find a lot of them to get an idea...

 

Greetings

Red Knight

Yup I always use virtual destructors too. :) only thing like I said is we should move programming discusions where we cut and paste code to to a mailing list. I was against the mailing list thing before but I now see that HTML is bad when showing code as example.

Link to comment
Share on other sites

×
×
  • Create New...