Jump to content


Photo

Programming Convention


  • Please log in to reply
7 replies to this topic

#1 Timil

Timil

    Captain

  • Forum Members
  • PipPipPipPip
  • 132 posts

Posted 17 December 2002 - 05:20 AM

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?
Grenadoholic

#2 Guest_stewart_*

Guest_stewart_*
  • Guests

Posted 17 December 2002 - 12:49 PM

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.

#3 red knight

red knight

    Xenocide Project Leader

  • Xenocide Inactive
  • 3,310 posts

Posted 17 December 2002 - 01:02 PM

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
Sourceforge Nick: flois - Federico Andres Lois
Visit my blog at: flois.blogspot.com

Posted Image

Pookie cover me, I am going in.

#4 Guest_stewart_*

Guest_stewart_*
  • Guests

Posted 17 December 2002 - 01:08 PM

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.

#5 red knight

red knight

    Xenocide Project Leader

  • Xenocide Inactive
  • 3,310 posts

Posted 17 December 2002 - 01:15 PM

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

Word Wrap, can you explain it???

Greetings
Red Knight
Sourceforge Nick: flois - Federico Andres Lois
Visit my blog at: flois.blogspot.com

Posted Image

Pookie cover me, I am going in.

#6 Guest_stewart_*

Guest_stewart_*
  • Guests

Posted 18 December 2002 - 12:46 PM

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.

#7 gangsta

gangsta

    Colonel

  • Forum Members
  • PipPipPipPipPip
  • 2,203 posts

Posted 19 December 2002 - 01:40 PM

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 :)
Posted Image

#8 gangsta

gangsta

    Colonel

  • Forum Members
  • PipPipPipPipPip
  • 2,203 posts

Posted 19 December 2002 - 01:42 PM

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.
Posted Image