You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(2) |
Oct
(3) |
Nov
(1) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
From: Chad A. <ae...@vr...> - 2004-11-10 10:22:55
|
Lately I've been working on the official* Cal3D exporter for Maya, when I decided to do a quick google search to see if there were other people heading down the same paths as me... and I ran across you guys. :) What is the state of your Maya -> Cal3D exporter? Does it export skeletons, animations, meshes, and materials? Would you be averse to contributing it to the Cal3D project? Does it have any external dependencies? Question on the side: Do you use Maya only on Windows or on other platforms as well? Lots and lots of people would love to have a Cal3D exporter for Maya, so it would be awesome if we could work together on this. Thank you, Chad * It's only "official" because its home is the Cal3D CVS repository. I'm combining the independent efforts of several people in order to get it working. |
From: Bertolt S. <ber...@in...> - 2003-05-20 17:17:21
|
Hallo Wir haben es jetzt endlich geschafft das neue Repository mit der odc-engine hochzuladen! -> Auf unserer Sourceforge-Projektseite kann man ab sofort mit cvs das Modul odc-engine auschecken. mfg Bertolt |
From: Info <in...@wi...> - 2003-03-20 20:36:52
|
Hi all, I didn't know where to send this so I subsribe to the mailing list. I have downloaded the maya exporter tool from CVS and found two littles = bugs: In file odcExportMesh2Cmd.cpp the line #define DllExport __desclspec( dllexport ); DllExport MStatus intializePlugin(MObject obj); DllExport MStatus unintializePlugin(MObject obj); // = <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D should be added, maya 4.5 complained that it couldn't find it. Also in the latest CVS, the two .mel files are not included (and the = plugin don't want to work without them :) And a little suggestions: for the msvc project file, the multi-threaded = dll should be included staticly since people that are not programmer = usually don't have those dll on their machine and maya don't give any = clue why the plugin wasn't loaded. Ben. |
From: Thomas H. <tho...@in...> - 2002-12-03 20:30:58
|
Hi all! For the network part of Neverending-ODC, we need another library, SDL_net. So please be prepared to have it installed when you will do the next "cvs update" since I already added it to the configure.in file. Another point is that it would be nice if we could get fully rid of the Expat library and use the libxml2 library of www.xmlsoft.org and its C++ wrapper "xmlwrapp" instead. ODC can be already compiled without expat (use"configure--with-xmlwrapp"), so please check it if this works fine for you, too (especially the Windows developers here). Thomas |
From: Holger D. <hol...@in...> - 2002-11-07 19:09:06
|
The branch core-reconstruction-3 is now merged with the main branch. Its job was to prepare the code of the client for the lab at the university of Ulm. This is mainly done now. The following files are still remains fr= om the old version but they will soon be reintegrated: src/world/actionManager.cpp/h src/world/gameObjects/* src/engine3d/skyCube.cpp/h src/engine3d/terrainRenderer.cpp/h =46rom now on you should work no longer on the branch core-reconstruction= -3. If you have made changes to the branch core-reconstruction-3 later than 07.11.2002 18:40 and don't know how to merge them conveniently with the main branch, please contact me. There is also a new datapack online but it has only a few changes to the old version (two new meshs and one texture). - Holger Dammertz - |
From: Holger D. <hol...@in...> - 2002-10-22 21:22:57
|
I've released the first datapack for the client. It can be downloaded fro= m the=20 project sites. There isn't much in yet: just a texture, a mesh and some G= UI data. If you want to be notified when a new datapack is released, you can monit= or this package. The objectloading and integration in the WorldTree now works basically bu= t there are two bugs, that need to be fixed soon: One seems to be in the Vector3D class (Segmentation fault while accessing a Vector3D) The other is, that the clean up at program end causes an segmentation fau= lt when no textures were loaded (but if I run the program with gdb, no error= =20 occured). - Holger Dammertz - |
From: Holger D. <hol...@in...> - 2002-10-17 20:22:17
|
The client/server coding conventions version 1.1.2 are now online. You ca= n=20 download them from the homepage www.neverending-odc.de. The only change (beside some typing corrections) to version 1.1.1 (former= =20 known as 1.0) is, that you not only have to mark a pointer variable with = _p=20 but also a reference variable with _r. The coding conventions source file is now also in the CVS tree (at the mo= ment=20 just under the branch core-reconstruction-3). You'll find it in docs/codingConventions.tex The versioning-system works as follows: - If you make only minor changes like correcting some typing errors or do= some reformatting, the third version number has to be increased by one (just= as happend above). - When you add a new paragraph or add/change some rules (that were discus= sed before of course) the middle number has to be increased by one. The th= ird number will go down to one again. When you do this, you should notify all developers with a mail to the developer mailinglist. - If you add a whole new Section (or do sth similar important) the first version number has to be increased by one and the others go down to one= =2E When you do this, send a mail to the developer mailing list and post a = news- message on the sourceforge project page. - Holger Dammertz - |
From: Holger D. <hol...@in...> - 2002-10-13 19:23:25
|
The Neverending ODC coding conventions are now online and can be download= ed from the homepage (http://www.neverending-odc.de). If you find errors or have some additions, please contact me. - Holger Dammertz -=20 |
From: Holger D. <hol...@in...> - 2002-09-16 16:54:34
|
Hi, there is now a new branch of the client cvs project, called=20 core-reconstruction-3. The main purpose for this branch is to prepare the game engine core for t= he=20 lab at university in the upcoming semester and to integrate the new=20 interface/scene-graph structure. The new brach will be merged with the ma= in=20 branch at the latest in mid october (and hopefully it will work properly=20 then). with a <cvs update -r core-reconstruction-3> you can convert your current= =20 working dir to use the new branch. All chages you make now to the source = will=20 only affect the new branch. But I suggest to create a backup of the current main brach or generate a = new=20 working dir with <cvs -z3 -d:ext:dev...@cv...:/cvsroot/ne-odc=20 co -r core-reconstruction-3 client> because a lot of files will be moved or deleted and you probably want to = reuse=20 your existing code (of course you can also checkout the main branch again= ). remark: you can check with <cvs status filename> the revisions, you are working o= n. If=20 it looks like this, everything is fine: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D File: Makefile.am Status: Up-to-date Working revision: 1.1.2.1 Repository revision: 1.1.2.1 /cvsroot/ne-odc/client/Attic/Makefile.am,= v Sticky Tag: core-reconstruction-3 (branch: 1.1.2) Sticky Date: (none) Sticky Options: (none) In the core-reconstruction-3 branch is now basic automake/autoconf suppor= t. You have to run the configure script once to generate the makefiles and then you can compile by just typing make. At the moment, just a test-program is compiled (src/client/client.cpp) wh= ich can be executed with the client.sh shell script in the main directory. Holger Dammertz |
From: Bertolt S. <ber...@in...> - 2002-09-09 11:55:17
|
Am Samstag, 31. August 2002 19:35 schrieb Thomas Huth: > On Thu, 29 Aug 2002 08:28:46 +0200, Holger Dammertz wrote: > > General/Unsorted: > > ------------------ > > - Always put the constant on the left hand side of an equality/inequa= lity > > comparison (I think the reason should be clear). For example: > > if (6 =3D=3D iErrorNum) > > Ok, this might be usefull for avoiding the "=3D" vs. "=3D=3D" typo... b= ut it is > IMHO quite unusual to always write comparisons this way (and looks quit= e > ugly in my eyes, too). Experienced C/C++/Java coders also shouldn't hav= e > problems with this typing error, so I would prefer to drop this rule. I agree, we can drop this rule. > > - Methods should limit themselves to a single page of code. what to do if not? > > > - each class should have it's own .h and .cpp file (and this are the = only > > allowed extensions) > > What about totally virtual classes? Their .cpp would be empty. Can it b= e > omitted then? Generally yes. But in a Java GUI i.e. you will have lots of ActionListener-classes for o= nly=20 one Button. We should declare exceptions from this rule. > > > Formatting Conventions: > > ------------------------ > > - one space after a comma, an "if" or an "switch": > > if ((1 =3D=3D iCount) || (5 =3D=3D CalcMax(7, 19))) > > { > > ... > > } > > Why spaces after an "if" or "switch"? I always saw "if" and "switch" li= ke > normal function calls, and you normally don't add a space there, too! > And what about "for" and "while" expressions? one space after a comma is usual I think it don't care if there is a space after an "if", "switch", ... or= not > > > - Declaration blocks should be aligned in the following way: > > /** comment */ > > GMesh3D* m_pMesh; > > GSubMesh3D* m_pSubMesh; > > /** comment */ > > float* m_pRotMatrix; > > First this seems to be a good idea... but then: What if you have to add= a > new variable with a very long type name later? E.g.: > > GVeryVeryLongTypeName3D* m_dontKnowWhat; > > =3D> Then you have to re-align all other variables in that declaration = block, > this is a lot of anoying extra-work and makes CVS-diffs less readable. > Since there is already another rule for better readability ("only decla= re > one variable per line"), I would like to see this rule to be dropped, t= oo. I don't see an advantage in this rule... But Thomas mentioned many disadvantages. > > - Similarly blocks of initialization of variables should be tabulated= : > > clpInstance =3D this; > > iActiveElements =3D 0; > > Same as above. I don't think it's a good idea. > > - if (condition) // Comment > > { > > } > > else if (condition) // Comment > > { > > } > > else // Comment > > { > > } > > The way that you placed the comments, you will often run in trouble > regarding the 78-colums rule... First: -open bracket in a new line Second: possibilities where to place the comment: 1.=20 if (condition) { // comment ... } // end comment 2. if (condition) { // comment ... } // end comment the "end comment" is optional. I think its useful if there is a high=20 identation level. So you can easier see what block this }-bracket closes. > > > - switch (...) > > { > > case 1: > > ... > > // FALL THROUGH > > case 2: > > { > > int v; > > ... > > } > > break; > > > > default: > > } > > This example seems to be very confusing: What do you want to say exactl= y > with it? And how to exactly indent the instructions between two case > clauses? You should write such examples without an describing text abov= e > it. > BTW: Most of those "Formatting conventions" can simply be covered by > declaring a certain "indent" or "astyle" format. So every coder could u= se > indent or astyle to format his source code in the right way before > committing it to the CVS repository. (BTW: I'm not sure if indent also > supports C++, and since astyle also supports Java, this or something > equivalent might be the better choice). I think thats a good idea. > > > Naming Conventions: > > -------------------- > > > > Method Naming: > > - The first character in the name is upper case (this could > > be discussed, but see my reason below) > > > > Member Variable Naming: > > I have two possible conventions in mind: > > 1; (similar to what we are using already) > > - all member variables start with a lower case letter > > - private member variables start with an underbar > > When methods start with a upper case letter and variables with > > a lower case letter, they are easyly distinguishable. > > Methods and variables are _already easyly distinguishable, since method= s > have a bracket afterwards! So I really like to keep it like the old way > was, variables and methods both starting with a lowercase letter. Also = note > that you won't be able to distinguish methods and classes when both sta= rt > with a capital letter! I think this is our habit. > > > 2; (I would prefer this) > > - each variable starts with a prefix (describing access type and > > data type) and then apply the same rules as for method naming: > > Access Prefix: > > m before the name of a member variable > > ms before the name of a static variable > > (Perhaps we could add here some more to distinguish between > > public, protected and private variables; > > The hungarian notation uses also g and gs for global (static) > > variables.) > > This prefix method also sounds quite usable, but I wouldn't add a lette= r > for that public/protected/private stuff, since this might change someti= mes > and then you have to rename all places where the variable occurs in the > source code. > > > Data Types: > > p for a pointer > > s for int16/short > > us for uint16 > > i for int32 > > ui for uint32 > > q for int64 > > uq for uint64 > > f for real32/float > > d for real64/double > > b for bool > > uc for uint8 or byte > > sz for a C string > > str for a STL string > > tag for any struct > > cl for any class > > ct for any enum > > Well, I really don't like that Hungarian notation method - for example = what > if you change the type of a variable (e.g. from float to double)? Yes, = you > have to rename it everywhere in the source code. If you want to know ab= out > the type of a variable, simply have a look in the tiny .h file or the > documentation generated by Doxygen. > > > Perhaps it might be more readable to write an underbar after the > > access prefix (for example: Mesh3D* m_clpGraphicMesh) > > Oh no, yet another key more to type ;-) But it really looks better, I > think. I don't mind. > > > What also needs to be defined (but I wait for your suggestions): > > - the get and set methods > > Why needs this extra definitions? Simply write a getVariable() and a > setVariable() method!? thats right > > > - single line comments (in the code) should be written in this form: > > /* comment */ > > some code... > > What about: > // comment > some code... > ??? Why not "// comment" ? > > > BTW: What about comments in the .cpp fiels to separate methods? Or what > about separation lines like this: > //******************************************************* > Should/Must they be used in the code? > what about this? (or something similar) // *************** method name above ******************** // // ------------------ method name below -------------------------- > > Open points: > > - How strict should we force the use of a centralized logger=20 > > (->error-handling)? we can say, if s.o. commit code into CVS there isn't any system.out.print= ln()=20 in the code (or only in outcommented form for future testing) > Thomas |
From: Thomas H. <tho...@in...> - 2002-08-31 17:41:31
|
On Thu, 29 Aug 2002 08:28:46 +0200, Holger Dammertz wrote: > Below you'll find a first draft of some rules that could serve as a basis > for discussion (and extension, because I'm sure I forgot lot's of quite > important things) > >... > General/Unsorted: > ------------------ > - Always put the constant on the left hand side of an equality/inequality > comparison (I think the reason should be clear). For example: > if (6 == iErrorNum) Ok, this might be usefull for avoiding the "=" vs. "==" typo... but it is IMHO quite unusual to always write comparisons this way (and looks quite ugly in my eyes, too). Experienced C/C++/Java coders also shouldn't have problems with this typing error, so I would prefer to drop this rule. > - each class should have it's own .h and .cpp file (and this are the only > allowed extensions) What about totally virtual classes? Their .cpp would be empty. Can it be omitted then? > Formatting Conventions: > ------------------------ > - one space after a comma, an "if" or an "switch": > if ((1 == iCount) || (5 == CalcMax(7, 19))) > { > ... > } Why spaces after an "if" or "switch"? I always saw "if" and "switch" like normal function calls, and you normally don't add a space there, too! And what about "for" and "while" expressions? > - Declaration blocks should be aligned in the following way: > /** comment */ > GMesh3D* m_pMesh; > GSubMesh3D* m_pSubMesh; > /** comment */ > float* m_pRotMatrix; First this seems to be a good idea... but then: What if you have to add a new variable with a very long type name later? E.g.: GVeryVeryLongTypeName3D* m_dontKnowWhat; => Then you have to re-align all other variables in that declaration block, this is a lot of anoying extra-work and makes CVS-diffs less readable. Since there is already another rule for better readability ("only declare one variable per line"), I would like to see this rule to be dropped, too. > - Similarly blocks of initialization of variables should be tabulated: > clpInstance = this; > iActiveElements = 0; Same as above. I don't think it's a good idea. > - if (condition) // Comment > { > } > else if (condition) // Comment > { > } > else // Comment > { > } The way that you placed the comments, you will often run in trouble regarding the 78-colums rule... > - switch (...) > { > case 1: > ... > // FALL THROUGH > case 2: > { > int v; > ... > } > break; > > default: > } This example seems to be very confusing: What do you want to say exactly with it? And how to exactly indent the instructions between two case clauses? You should write such examples without an describing text above it. BTW: Most of those "Formatting conventions" can simply be covered by declaring a certain "indent" or "astyle" format. So every coder could use indent or astyle to format his source code in the right way before committing it to the CVS repository. (BTW: I'm not sure if indent also supports C++, and since astyle also supports Java, this or something equivalent might be the better choice). > Naming Conventions: > -------------------- > > Method Naming: > - The first character in the name is upper case (this could > be discussed, but see my reason below) > > Member Variable Naming: > I have two possible conventions in mind: > 1; (similar to what we are using already) > - all member variables start with a lower case letter > - private member variables start with an underbar > When methods start with a upper case letter and variables with > a lower case letter, they are easyly distinguishable. Methods and variables are _already easyly distinguishable, since methods have a bracket afterwards! So I really like to keep it like the old way was, variables and methods both starting with a lowercase letter. Also note that you won't be able to distinguish methods and classes when both start with a capital letter! > 2; (I would prefer this) > - each variable starts with a prefix (describing access type and > data type) and then apply the same rules as for method naming: > Access Prefix: > m before the name of a member variable > ms before the name of a static variable > (Perhaps we could add here some more to distinguish between > public, protected and private variables; > The hungarian notation uses also g and gs for global (static) > variables.) This prefix method also sounds quite usable, but I wouldn't add a letter for that public/protected/private stuff, since this might change sometimes and then you have to rename all places where the variable occurs in the source code. > Data Types: > p for a pointer > s for int16/short > us for uint16 > i for int32 > ui for uint32 > q for int64 > uq for uint64 > f for real32/float > d for real64/double > b for bool > uc for uint8 or byte > sz for a C string > str for a STL string > tag for any struct > cl for any class > ct for any enum Well, I really don't like that Hungarian notation method - for example what if you change the type of a variable (e.g. from float to double)? Yes, you have to rename it everywhere in the source code. If you want to know about the type of a variable, simply have a look in the tiny .h file or the documentation generated by Doxygen. > Perhaps it might be more readable to write an underbar after the > access prefix (for example: Mesh3D* m_clpGraphicMesh) Oh no, yet another key more to type ;-) But it really looks better, I think. > What also needs to be defined (but I wait for your suggestions): > - the get and set methods Why needs this extra definitions? Simply write a getVariable() and a setVariable() method!? > - naming conventions for parameters in methods (for example it might > be usefull to see, if its just a "normal" parameter or it > changes sth. that lasts longer than the method call) That's what the "const" key word is good for. > - #define's and C-functions (if we dont ban them at all) #defines should hardly be necessary in a C++ program, so what about a rule that says to use "const int" declarations instead? C functions should really be banned in a clean C++ project - apart from the C functions of the various libraries (e.g. SDL, ...). > Documentation: > --------------- > - All files must include the standardized header. #include "standardizedHeader.h" ? ;-) > - single line comments (in the code) should be written in this form: > /* comment */ > some code... What about: // comment some code... ??? BTW: What about comments in the .cpp fiels to separate methods? Or what about separation lines like this: //******************************************************* Should/Must they be used in the code? > Open points: > ------------- > - Do we need to define namespaces? Sooner or later, we will need this to avoid name conflicts with the various libraries we are using... > - should we correct all warnings a compiler generates It is normally a very good idea. Simply add a "-Wall -Werror" to the CFLAGS in the Makefile and all warnings will have to be fixed! > - Do we need to typedef our own datatypes (like uint16...) No, simply #include <sys/types.h> > - How are errors handled (return-types, storing an error string somewhere...) What about throwing exceptions? Thomas |
From: Holger D. <hol...@in...> - 2002-08-29 06:27:41
|
Hi since ODC becomes a quite big project now, the time to define and write d= own=20 some coding conventions has come. The reasons why some (or more) commonly= =20 used rules and conventions make sense are among others: - we have a consistent style - code is easy to read and to understand - code will be (hopefully) more portable to other platforms - common errors are avoided - code is easier to maintain by different programmers Below you'll find a first draft of some rules that could serve as a basis= =20 for discussion (and extension, because I'm sure I forgot lot's of quite important things) - Holger Dammertz -------------------------------------------------------------------------= ----- =09 Neverending ODC - Coding Rules and Conventions =09=09=09 Holger Dammertz =09=09=09 28.08.2002 The following rules and conventions are just suggestions of what might be usefull in the development of ODC. Indeed they are quite unstructured and are intended as a base to come to a common consens. Some of the rules are only for C++ but some of them might be also used in the other programming languages we use (Java, Python...) General/Unsorted: ------------------ - Every time a rule is broken, this must be clearly documented.=20 - All data stored in files or send through the network should be big endi= an - Always put the constant on the left hand side of an equality/inequality comparison (I think the reason should be clear). For example: if (6 =3D=3D iErrorNum) - There should be only one statement per line unless the statements are v= ery closely related. - Methods should limit themselves to a single page of code. - don't #define macros, use inline methods - usually avoid embedded assignments - each class should have it's own .h and .cpp file (and this are the only= =20 allowed extensions) - You shall always initialize variables. Always. Every time.=20 - Classes with multiple constructors and/or multiple attributes should de= fine=20 a private InitObject() method to initialize all attributes. - The constructor of a class should never rely on the success of another function call --> only initialize member variables and set pointers to = NULL. Instead define a public Init() method the prepares the object for its u= se (and manages errors). =20 Formatting Conventions: ------------------------ - NO TABS - 2 spaces per indentation level - no spaces after an open or before a closing bracket. - one space after a comma, an "if" or an "switch": if ((1 =3D=3D iCount) || (5 =3D=3D CalcMax(7, 19))) { ... } - Lines should not exceed 78 characters (not only because it's easyer to get the code on screen, but because of printing the source code=20 (and diff's) gets much easier). - Only one variable declaration per line (except they are no pointers and have really very much in common) - Declaration blocks should be aligned in the following way: /** comment */ GMesh3D* m_pMesh; GSubMesh3D* m_pSubMesh; /** comment */ float* m_pRotMatrix; =20 - The '&' and '*' tokens should be adjacent to the type, not the name. - Similarly blocks of initialization of variables should be tabulated: clpInstance =3D this; iActiveElements =3D 0; bActive =3D false; bMouseActive =3D false; - if (condition) // Comment { } else if (condition) // Comment { } else // Comment { } - switch (...) { case 1: ... // FALL THROUGH case 2: { int v; ... } break; default: } - Falling through a case statement into the next case statement shall be permitted as long as a comment is included. - The default case should always be present and trigger an error if it s= hould=20 not be reached, yet is reached. =20 Naming Conventions: -------------------- General: - Abbreviations should be written with only the first letter uppercase: GuiManager (not GUIManager) Class Naming: - The first character in the name is upper case - Upper case letters are used as word separators (no underbars) Method Naming: - The first character in the name is upper case (this could be discussed, but see my reason below) - Upper case letters are used as word separators (no underbars) Member Variable Naming: I have two possible conventions in mind: 1; (similar to what we are using already) - all member variables start with a lower case letter - private member variables start with an underbar When methods start with a upper case letter and variables with a lower case letter, they are easyly distinguishable. 2; (I would prefer this) - each variable starts with a prefix (describing access type and data type) and then apply the same rules as for method naming: Access Prefix: m before the name of a member variable ms before the name of a static variable (Perhaps we could add here some more to distinguish between public, protected and private variables; The hungarian notation uses also g and gs for global (static) variables.) Data Types: p for a pointer s for int16/short us for uint16 i for int32 ui for uint32 q for int64 uq for uint64 f for real32/float d for real64/double b for bool uc for uint8 or byte sz for a C string str for a STL string tag for any struct cl for any class ct for any enum Perhaps it might be more readable to write an underbar after the access prefix (for example: Mesh3D* m_clpGraphicMesh) The access prefix let you see directly in the sourcecode whether a=20 member variable or a local variable is used. What also needs to be defined (but I wait for your suggestions): - the get and set methods - naming conventions for parameters in methods (for example it might be usefull to see, if its just a "normal" parameter or it changes sth. that lasts longer than the method call) - typedef's - #define's and C-functions (if we dont ban them at all) Documentation: --------------- - All files must include the standardized header.=20 - All comments are to be written in English.=20 - Classes are documented in their header files. - Document every method (in-depth and comprehensive) and every important member variable (short but also comprehensive) using the format, Doxyge= n can read (similar to javadoc): =20 /** this is a really important variable */ int iMaxBlah; /** this is also a really important variable, that has some more impo= rtant * documentation so it needs more than one line */ float fMinScale; /** * The first sentece should summerize the use of the method. * More documentation follows. * * @param description of the parameters * @returns description of the return value */ void DoSthImportant(); - Every class should have a good documentation (how and why it is used): /** * The first sentece should summerize the use of the class. * More documentation follows. * * @author Your Name * [@version x.x] (Only when the class is important to many other * people) */ class Mesh3D... - single line comments (in the code) should be written in this form: /* comment */ some code... multiple line comments this way: /* comment more comments and even more */ some code... - when you use this style of documentation you cannot comment out multipl= e lines of code with just a /*....*/ but instead you can do the following= : void SomeClass::Example() { great looking code #if 0 . lots of code . #endif more code } =20 In-Development comments (Gotchas): ----------------------------------- - After each gotcha keyword, the current date should appear: !!TODO: 020827 description of task - Gotcha keywords: !!TODO: topic Means, there is more to do here that you should not forget. !!BUG: description There is a known bug but either you don't how to do it or you have sth. more important to do. !!UGLY:=20 When you've done something ugly say so and explain how you would do=20 it differently next time if you had more time. !!OPT: You know, that sth. could be done significantly faster but have no time to do it yet; so explain here what should be done instead, and why it is better/faster. !!FIXME: The primordial gotcha (similar to !!TODO: but the task should be done quite fast) !!TRICKY: The following code was done a bit tricky and you should explain why you have not done it simpler. The keywords are marked special so you can find them eaysily by searching for !! in your source file. It is also possible to create a tool that automatically generates a report. Open points: ------------- - How intense should we use abstract base classes to minimize dependencies? - Do we need an own Runtime Type Identification system? - Information hiding? - Do we need to define namespaces? - should we correct all warnings a compiler generates - Do we need to typedef our own datatypes (like uint16...) - How are errors handled (return-types, storing an error string somewhere= =2E..) - How strict should we force the use of a centralized logger (->error- handling)? - Should we create header-files, that include common used sub-files and define some prequisites? - How do we standardize the building process (and how much does it=20 affect the file structure...) References [1] C/C++ Kompendium - Dirk Louis - 1998 Markt und Technik, Buch und Software-Verl. ISBN 3-8272-5386-1 [2] C++ Coding Standard - Tedd Hoff - 2000 http://www.cs.umd.edu/users/cml/cstyle/CppCodingStandard.html [3] Programming in C++, Rules and Recommendations -=20 FN/Mats Henricson and Erik Nyquist - 1992 http://www.cs.umd.edu/users/cml/cstyle/Ellemtel-rules.html [4] OGRE Coding Standards - http://ogre.sourceforge.net=20 |