Why do these need to be variables? They belong in the header of the source, not in memory space while the program is running.uzurpator wrote:A class has to have the following static fields:
...
long int Version; // unix time stamp of the date the file was uploaded
char Status; // status of the class: accepted, beta, alpha, final etc.
...
Coding standard
Moderator: Transport Empire Moderators
Grunt
(aka Stephan Grunt, CEO of Grunt Transport Inc. since 1994.)
(aka Stephan Grunt, CEO of Grunt Transport Inc. since 1994.)
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
Grunt:
or
Click on the class,ethod tree vs doing nothing (or alt-tabbing)
I say it's an improvement
If you have updated headers, then you have to recompile the whole project - because you don't know where the *.h were used. If you didn't touch the headers, then only changed *.cpp will be compiled.
If you updated three 5 kb methods - you compile 15 kb of code. However if those methods were in three seperate files 50 kb each - then you will compile 150 kb of code.
Roughly 10 times faster.
Ofc using vc software is not an option, but nonetheless - having another level of maintaing order is IMVHO a good idea.
As for the two fields - it will make it possible to build in a self checker that can trace potential incompatibilities on runtime. BTW - 'author' field would also be needed methinks.
Besides - these are static fields - shared among the objects - even with 1000 classes they will take a few kb of memory...
fujitsu:
Consider this:
class.h
example header for 'class'.
For any outside class it works the same as it all was in a single header (kind of needs to be to compile). Seperate *.h however will make it easier to understand as a whole, You probably know that ferinstance UML diagrams start to get difficult to read if there are more then, say, 7-8 boxes visible - the same rule applies here.
EDIT: BTW - anybody knows a good code beautyfier?
Which makes it more troublesome to open a file, which you do one time.Grunt wrote:..which makes for one more directory level you have to traverse when looking for the source file you need to work with.
Ctrl+F,type what you seek,enter vs doing nothing (or alt-tabbing)Most text editors have find features for exactly this reason.
or
Click on the class,ethod tree vs doing nothing (or alt-tabbing)
I say it's an improvement
It will...however, there will be code repeated throughout every source file (thinking of header files, primarily); then there is a lot more code (from the perspective of the compiler) to work through, so this approach would result in longer compilation times, no? EDIT: in either case, you have the same amount of method code to compile, and whether or not that code is broken down into individual files or lumped together in one big file will itself make no difference in compilation time.
If you have updated headers, then you have to recompile the whole project - because you don't know where the *.h were used. If you didn't touch the headers, then only changed *.cpp will be compiled.
If you updated three 5 kb methods - you compile 15 kb of code. However if those methods were in three seperate files 50 kb each - then you will compile 150 kb of code.
Roughly 10 times faster.
Line 124? 274? Before/after class b? This is small stuff, but important in the convinence of the work....in the file of the associated class, of course.
Version control requires maintenence on each change of the code. Splitting *.cpp and *.h at 1 per method does not.Untrue - any recent version control software (CVS, SVN) will merge changes as described above if they are made at the same time to the same file assuming the two changes are not diametrically opposed, which, by the description of editing two different methods, is not going to happen in the circumstances you describe.
Ofc using vc software is not an option, but nonetheless - having another level of maintaing order is IMVHO a good idea.
As for the two fields - it will make it possible to build in a self checker that can trace potential incompatibilities on runtime. BTW - 'author' field would also be needed methinks.
Besides - these are static fields - shared among the objects - even with 1000 classes they will take a few kb of memory...
fujitsu:
Consider this:
class.h
Code: Select all
"include method.h"
"include method2.h"
"include method3.h"
"include method4.h"
parclass class //constructor parameters
{
public:
int par;
};
class class
{
private:
int field1;
int field2;
int field3;
public:
class(parclass *parameter);
~class();
resmethod *method(parmethod *parameter);
resmethod2 *method2(parmethod2 *parameter);
resmethod3 *method3(parmethod3 *parameter);
};
For any outside class it works the same as it all was in a single header (kind of needs to be to compile). Seperate *.h however will make it easier to understand as a whole, You probably know that ferinstance UML diagrams start to get difficult to read if there are more then, say, 7-8 boxes visible - the same rule applies here.
EDIT: BTW - anybody knows a good code beautyfier?
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
-
- Transport Empire Developer
- Posts: 699
- Joined: 03 Feb 2003 09:30
- Location: Back at the office
I have no problems with having one cpp file (and perhaps even a header file) for each method. I even think this might help us, but I just can't find another example. So I'm not going to say another word about it, except: ok.
It's this what puzzles me:
I prefer the following style (don't flame just yet, there is more text below. )
But I don't have any problems with
So basically, my preference sums up to:
Also, note that I've edited your post, adding [code] tags.
It's this what puzzles me:
What is the function of the prefix and suffix? I just don't get it. If the variable name in itself is descriptive enough, why do we need a pre- and suffix?uzurpator wrote:prefix_Varname_suffix
prefix and suffix are up to the coder.
Varname is a string that should describe as a noun with adjectives
(two at most) and a qualification what the variable is:
So, each class must have an alias with the "res" prefix and one with the "par" prefix? It makes, IMHO, more sense to give the actual parameters of a method such a prefix. The return value is usually given through the "return" command.uzurpator wrote:The parameter/result class is always named
parMethodName
resMethodName
eg we have a method called DoStuff should be declared
resDoStuff *DoStuff(parDoStuff *par);
I don't see the point in mentioning this difference, but the place of the curly braces is strange, in my opinion.uzurpator wrote:is considered a single loop, butCode: Select all
for (int x=0;x<100;x++) for (int y=0;y<100;y++) { }
is considered two seperate loopsCode: Select all
for (int x=0;x<100;x++) { cout << "lol\n"; for (int y=0;y<100;y++) { } }
I prefer the following style (don't flame just yet, there is more text below. )
Code: Select all
for (int x = 0; x < 100; x++) {
a[x] = 0;
}
Code: Select all
for(int x=0; x<100; x++)
{
a[x]=0;
}
- I like to have the closing brace ( } ) on the same indentation level as the accompanying command
- I prefer having spaces around binary operators
Also, note that I've edited your post, adding [code] tags.
Feel free to contact me over Email! My current timezone: Europe/Amsterdam (GMT+1 or GMT+2)
[ General TE Discussion ] [ TE Development ] [ TE Coding ]
Under construction...
Code: Select all
+------------Oo.------+
| Transport Empire -> |
+---------------------+
Under construction...
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
Hellfire:
Prefix and suffix are for the coder to do whatever he wants with them. It is easy to strip the source of them during the beautification phase.
They are actual parameters - eg
They are just to avoid situations where you have methods that look like this
The sole fact of preparing the parameters will suffice to know what a given method does.
Also returning a pointer to a structure will suffice to make a method with several outputs.
Also - having structures(unions, objects - whatever) as parameters will suffice to make it sure that you don't need to update 200 places where the method is called.
EDIT:
As for the brackets - that is just my style - i always open a new scope with 2 space indent, newline, bracket, newline, 2 space indent and seemingly close the same way. THis way brackets limiting a scope are always in a single column. Makes it easier to close several scopes.
Prefix and suffix are for the coder to do whatever he wants with them. It is easy to strip the source of them during the beautification phase.
They are actual parameters - eg
Code: Select all
struct resDoStuff
{
int field1;
int field2;
int field3;
};
struct parDoStuff
{
int field1;
int field2;
int field3;
};
resDoStuff *DoStuff(parDoStuff *params);
Code: Select all
var = func(1,3,object->method2(5423)4,5,pointer->struct->pointer.tab,1774.22,func2(4322));
Also returning a pointer to a structure will suffice to make a method with several outputs.
Also - having structures(unions, objects - whatever) as parameters will suffice to make it sure that you don't need to update 200 places where the method is called.
EDIT:
As for the brackets - that is just my style - i always open a new scope with 2 space indent, newline, bracket, newline, 2 space indent and seemingly close the same way. THis way brackets limiting a scope are always in a single column. Makes it easier to close several scopes.
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
Ok - to spice this topic a bit.
What are the objections for the current coding standard proposition? Ferinstance - what will it make impossible to do, that is possible with other stanard?
We need to make agreements fast, and start coding the backbone. Clock is ticking guys!
What are the objections for the current coding standard proposition? Ferinstance - what will it make impossible to do, that is possible with other stanard?
We need to make agreements fast, and start coding the backbone. Clock is ticking guys!
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
Ping!
WTF - I wanted a sparkling discussion here - a post once per 2-3 days isn't really that much is it?
How the hell you want to make a game if you don't have time to post huh?
WTF - I wanted a sparkling discussion here - a post once per 2-3 days isn't really that much is it?
How the hell you want to make a game if you don't have time to post huh?
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
-
- Engineer
- Posts: 32
- Joined: 12 Jul 2005 08:14
- Location: Melbourne suburbs, Victoria, Australia (GMT+10)
Firstly, Pong!uzurpator wrote:Ping!
WTF - I wanted a sparkling discussion here - a post once per 2-3 days isn't really that much is it?
How the hell you want to make a game if you don't have time to post huh?
Secondly, school started two weeks ago here, and exams are coming up. From November 22 until January 28, I am 100% free time. That is my reason for the lack of responses.
I prefer the former, because I simply cannot stand not having spaces around operators, although I often have the opening brace on the same indentation level as the closing one, as it makes the code easier to work out.Hellfire wrote:I prefer the following style (don't flame just yet, there is more text below. )But I don't have any problems withCode: Select all
for (int x = 0; x < 100; x++) { a[x] = 0; }
So basically, my preference sums up to:Code: Select all
for(int x=0; x<100; x++) { a[x]=0; }
Of course, in the end I will comply to the indentation defined in the coding standard, whichever form that might be.
- I like to have the closing brace ( } ) on the same indentation level as the accompanying command
- I prefer having spaces around binary operators
The coding standard as developed in this thread is significantly better than the original.
I hope we get some more responses soon, and that this project can get into gear properly.
/me sends a ping to 255.255.255.255
William.
-
- TTDPatch Developer
- Posts: 417
- Joined: 13 Apr 2004 13:35
- Location: Eindhoven, Netherlands
- Contact:
perhaps a bit late response, but i just liked yo point out that having the "single method per file" style, will efectively make inline methods completely useless. Method's can only be inlined if their method body is known at compile time, so if every method is compiled completely separate from all other methods, no method will ever be inlined.
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
Transport Empire Coding Standard - ver 2.0
1. Source naming and distribution
2. Class requirements
3. Method requirements
4. Commenting
--
1.
Source files pending inclusion to the project must obey following rules:
Only .h, .cpp and .txt files are allowed
.h - is for defining classes, structures and unions
.cpp - is for implementation of methods
.txt - is a description of a class.
The rule is - each method has its own source file.
Naming goes as follows:
class definition is always
method implementations are
constructor and destructor of a class are in
method parameter structures are in
Ferinstance we have a class 'F00BAR' with methods 'dostuff1', 'domorestuff', 'dorestofthestuff'
The files for these would look like this
Note - each class has its own place in the class tree - and this place is represented by the fact that the sources will be placed in a directory named the same as the class inside. The directory tree will mimic the class diagram.
2.
A class has to have the following static fields:
class field names are built in this manner
prefix and suffix are up to the coder.
Varname is a string that should describe as a noun with adjectives (two at most) and a qualification what the variable is:
Structure - Ste
Pointer to structure - Stp
Double Pointer to structure - Std
Reference to structure - Str
Variable - Vae
Pointer to variable - Vap
Double Pointer to variable - Vad
Reference to variable - Var
Table - Tab
Object - Obe
Pointer to an object - Obp
Double pointer to an object - Obd
Refernce to an object - Obr
Other - Oth
For example:
3. Method requirements
Methods always get their parameters through the parameter class (defined in TEclass_func.h) or void. Even more - they must always do so with a pointer to an object.
Methods always return a pointer to an object or union(also defined in TEclass_func.h) or void - called result class.
Methods may in special cases use a pointer to a table as a parameter - but only in a case when there is only one parameter. Otherwise a structure must be used.
The parameter/result class has all fields as public and may contain parameterless constructor(s)/destructor or parameterless methods - altho it is advisible that the parameter/result object was basicly a structure (ie - no methods and default constructor/destructor)
The parameter/result class is always named
eg we have a method called DoStuff should be declared
The parameter/result class must have static field called
If the game is in Developer Mode before each call to a method the class the method was called from should check if the version the class is compatible with the version of the parameter/result classes in the current version of the parameter/result.
No class can call for methods of a class higher of the hierarchy tree.
Exception:
Inline methods are exempt from above, however they must follow such rigors:
They must be private
They must be defined in the *.cpp of the class that will use them
They can use straight parameters and return them (no need for objects)
They can only be used in the *.cpp where they are defined.
4. Commenting
- Each source file starts with a table that shows:
Timestamp of the file
Author
And a neat TE ascii art logo
- before each method declaration the following data should be included:
what the method does
how the method does it
why this way of doing things was chosen
before each class field a description of what it is needed for must be provided (what it is used for, is it private, and if so why etc)
before each loop a description must be provided what happens - how does it happen and why
note:
is considered a single loop, but
is considered two seperate loops
Before ach condition a description must be provided what is being decided
note: the same rules as for loops apply
1. Source naming and distribution
2. Class requirements
3. Method requirements
4. Commenting
--
1.
Source files pending inclusion to the project must obey following rules:
Only .h, .cpp and .txt files are allowed
.h - is for defining classes, structures and unions
.cpp - is for implementation of methods
.txt - is a description of a class.
The rule is - each method has its own source file.
Naming goes as follows:
class definition is always
Code: Select all
TEclass.h
Code: Select all
TEclass_methodx.cpp
Code: Select all
TEclass.cpp
Code: Select all
TEclass_methodx.cpp
The files for these would look like this
Code: Select all
TEF00BAR.h //definition of the class
TEF00BAR.cpp //constructor(s) and destructor
TEF00BAR_dostuff1.h
TEF00BAR_dostuff1.cpp
TEF00BAR_domorestuff.h
TEF00BAR_domorestuff.cpp
TEF00BAR_dorestofthestuff.h
TEF00BAR_dorestofthestuff.cpp
2.
A class has to have the following static fields:
Code: Select all
char[x] Author = 'author'; // a field containing a string with the author of the class (eg Uzurpator)
char[x] Name = 'classname'; // a field containing the name of the class (eg Terrain)
char[5] Abbreviation = 'class name short; // a field containing 4 letter abbreviation of the class (eg Tern)
long int Count; // a field contaning information how many instances of the class are there currently;
long int Version; // unix time stamp of the date the file was uploaded
char Status; // status of the class: accepted, beta, alpha, final etc.
Code: Select all
prefix_Varname_suffix
Varname is a string that should describe as a noun with adjectives (two at most) and a qualification what the variable is:
Structure - Ste
Pointer to structure - Stp
Double Pointer to structure - Std
Reference to structure - Str
Variable - Vae
Pointer to variable - Vap
Double Pointer to variable - Vad
Reference to variable - Var
Table - Tab
Object - Obe
Pointer to an object - Obp
Double pointer to an object - Obd
Refernce to an object - Obr
Other - Oth
For example:
Code: Select all
pgegd_TrackElementsOnTileVar_pps //is a variable with two affixes, named TrackElementsOnTile //and is a single variable (integer or somesuch)
TrackBendsTabVar //a table of variables (a table of ints, chars whatever)
TerrainTabObp_first /an affixed object pointer table
Methods always get their parameters through the parameter class (defined in TEclass_func.h) or void. Even more - they must always do so with a pointer to an object.
Methods always return a pointer to an object or union(also defined in TEclass_func.h) or void - called result class.
Methods may in special cases use a pointer to a table as a parameter - but only in a case when there is only one parameter. Otherwise a structure must be used.
The parameter/result class has all fields as public and may contain parameterless constructor(s)/destructor or parameterless methods - altho it is advisible that the parameter/result object was basicly a structure (ie - no methods and default constructor/destructor)
The parameter/result class is always named
Code: Select all
parMethodName
resMethodName
Code: Select all
resDoStuff *DoStuff(parDoStuff *par);
Code: Select all
int Version;
No class can call for methods of a class higher of the hierarchy tree.
Exception:
Inline methods are exempt from above, however they must follow such rigors:
They must be private
They must be defined in the *.cpp of the class that will use them
They can use straight parameters and return them (no need for objects)
They can only be used in the *.cpp where they are defined.
4. Commenting
- Each source file starts with a table that shows:
Timestamp of the file
Author
And a neat TE ascii art logo
- before each method declaration the following data should be included:
what the method does
how the method does it
why this way of doing things was chosen
before each class field a description of what it is needed for must be provided (what it is used for, is it private, and if so why etc)
before each loop a description must be provided what happens - how does it happen and why
note:
Code: Select all
for (int x=0;x<100;x++)
for (int y=0;y<100;y++)
{
}
Code: Select all
for (int x=0;x<100;x++)
{
cout << "lol\n";
for (int y=0;y<100;y++)
{
}
}
Before ach condition a description must be provided what is being decided
note: the same rules as for loops apply
Last edited by uzurpator on 25 Oct 2005 21:29, edited 1 time in total.
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
- DominionSpy
- Tycoon
- Posts: 1429
- Joined: 03 Oct 2003 23:59
- Location: Lancashire, UK
- Contact:
I've been away in Spain for 10 days, so I wasn't able to reply.uzurpator wrote:Ping!
WTF - I wanted a sparkling discussion here - a post once per 2-3 days isn't really that much is it?
How the hell you want to make a game if you don't have time to post huh?
With regard to the new coding standard:
Section 1: I am still against having a separate header file for each method. They should at least combined in a single file for each class.
Section 2: I don't think we should have an 'Author' field since hopefully many people will be working on the same files, it doesn't matter who started it.
I think the variable naming convention horrendous. For me, I would rather that we have a simple way of marking whether the variable is a member of the class or a local variable of the method. Then it's not cluttered with mostly useless information. If you can't work out the variable type from the context, it only takes a moment or two to find the definition (in the header file if it's a member variable or in the method declaration otherwise).
Section 3: I would like to know your reasoning for this parameter/results object passing. It seems like an unnecessary level of indirection to me.
Section 4: Again I think the Author is unnecessary. Otherwise it sounds good.
You're saying I'm a Dominion spy, and don't even know it! - Dr. Bashir
That's the Joker in my avatar, not me. No wait it is me.
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
Yet you still failed to provide why single file is superior to multiple files.DominionSpy wrote:Section 1: I am still against having a separate header file for each method. They should at least combined in a single file for each class.
cout << obj->author;Section 2: I don't think we should have an 'Author' field since hopefully many people will be working on the same files, it doesn't matter who started it.
Mek/n Uzurpator/n Mek/n DominionSpy/n
You can write a whole book there...
No info is ever uselessI think the variable naming convention horrendous. For me, I would rather that we have a simple way of marking whether the variable is a member of the class or a local variable of the method. Then it's not cluttered with mostly useless information.
Good point about the method locals. I'll add them to the next revision of the standard.If you can't work out the variable type from the context, it only takes a moment or two to find the definition (in the header file if it's a member variable or in the method declaration otherwise).
1. To prepare the parameter object you need to make a consious effort - so you will never forget what a parameter does.Section 3: I would like to know your reasoning for this parameter/results object passing. It seems like an unnecessary level of indirection to me.
2. When the parameter changes you will not have to update (write) 200 calls for a method.
3. When the parameter object changes the game will inform you where the object is used - which will shorten the amount of time needed to update all classes that use the method.
4. To avoid this:
Code: Select all
localclient = new LocalClient(10,map->Map,map->Heights,54,54,32,32,map->size_x,map->size_z);
Author is static - and provides info - we can strip it in final versions though (conditional compile)Section 4: Again I think the Author is unnecessary. Otherwise it sounds good.
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
- DominionSpy
- Tycoon
- Posts: 1429
- Joined: 03 Oct 2003 23:59
- Location: Lancashire, UK
- Contact:
Actually I said this:uzurpator wrote:Yet you still failed to provide why single file is superior to multiple files.DominionSpy wrote:Section 1: I am still against having a separate header file for each method. They should at least combined in a single file for each class.
But for another reason I'll give you an example. Like your example there is a class called 'F00BAR' with methods 'dostuff1', 'domorestuff', and 'dorestofthestuff'.DominionSpy wrote:I'm not sure about the separate header files for each method though. I think it would be more useful to have a single header file for each class. The separate ones would only have one line in and a single one could also act as an index for reference.
Say a method from another class wants to access F00BAR and all three of its methods. It would have to have 4 includes just for the current number of methods. Imagine if one of our classes had 30 methods and a method had to access them. It's better to have one point of entry for all the class methods.
That's simply not true - information is only useful in the right context. If someone is choking, then the information about how to brew beer is useless in that situation.uzurpator wrote:No info is ever uselessI think the variable naming convention horrendous. For me, I would rather that we have a simple way of marking whether the variable is a member of the class or a local variable of the method. Then it's not cluttered with mostly useless information.
However, I didn't really mean 'useless'. I should have said 'unneeded'.
PS I don't whether it's just a communication problem, but it seems to me like you're taking these comments personally.
You're saying I'm a Dominion spy, and don't even know it! - Dr. Bashir
That's the Joker in my avatar, not me. No wait it is me.
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
I understand your concerns.DominionSpy wrote:Say a method from another class wants to access F00BAR and all three of its methods. It would have to have 4 includes just for the current number of methods. Imagine if one of our classes had 30 methods and a method had to access them. It's better to have one point of entry for all the class methods.
But as I already showed to fujitsu - if you include all the method headers in the class header - then it works precisely the same way as if it was a single file.
Preprocessor will simply replace all includes with an actual file. This way anything that needs anything from F00BAR will simply include F00BAR.h.
Actually - you could do the same trick with actual method .cpp. INclude them at the end of the F00BAR.cpp (the constructor/destructor code file) - but that would require to mark them as 'do not compile' in the project (as they would be compiled with the F00BAR.cpp) - but imho that is inelegant.
Hmm - yes. I can agree with that. But - if those fields prove useless (or uneeded - whichever) it is not much hassle to delete them - is it?That's simply not true - information is only useful in the right context. If someone is choking, then the information about how to brew beer is useless in that situation.
However, I didn't really mean 'useless'. I should have said 'unneeded'.
Well - I'm a rather blunt person - and considering that english is not my native language... it may come up in very bizarre waysPS I don't whether it's just a communication problem, but it seems to me like you're taking these comments personally.
EDIT:
Another thing that got to my mind - should we use exceptions for error handling?
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
OK - the revised coding standard:
The biggest change - i got rid of the variable naming standard. In action it only got things murkier.
Also - the requirement of each method be in a folder that mimics its position in a tree. Frankly because the class tree is actually a class graph.
For now each method just requires its own folder.
----
Transport Empire Coding Standard ver 3.0
1. Source naming and distribution
2. Class requirements
3. Method requirements
4. Commenting
5. Error Handling
--
1.
Source files pending inclusion to the project must obey following rules:
Only .h, .cpp and .txt files are allowed
.h - is for defining classes and structures
.cpp - is for implementation of methods
.txt - is a description of a class.
The rule is - each method has its own source file.
Naming goes as follows:
class definition is always
TeClass.h
method implementations are
TeClass_Method.cpp
constructor and destructor of a class are in
TcClass.cpp
method parameter structures are in
TeClass_Methodx.cpp
Ferinstance we have a class 'F00BAR' with methods 'DoStuff1', 'DoMoreStuff', 'DoRestOfTheStuff'
The files for these would look like this
TEF00BAR.h //definition of the class
TEF00BAR.cpp //constructor(s) and destructor
TEF00BAR_DoStuff1.h
TEF00BAR_DoStuff1.cpp
TEF00BAR_DoMoreStuff.h
TEF00BAR_DoMoreStuff.cpp
TEF00BAR_DoRestOfTheStuff.h
TEF00BAR_DoRestOfTheStuff.cpp
Each class is stored in a folder named after it - eg TEF00BAR is stored in TEF00BAR folder.
2.
A class has to have the following static fields:
std::string Author = 'author'; // a field containing a string with the author of the class (eg Uzurpator)
std::string Name = 'classname'; // a field containing the name of the class (eg Terrain)
std::string Abbreviation = 'class name short; // a field containing 4 letter abbreviation of the class (eg Tern)
long int Count; // a field contaning information how many instances of the class are there currently;
long int Version; // unix time stamp of the date the file was uploaded
char Status; // status of the class: accepted, beta, alpha, final etc.
class field names are built in this manner
prefix_Varname_suffix
prefix and suffix are up to the coder (eg - a coder may, or may not choose to use them).
Varname is a string that should describe as a noun with adjectives.
3. Method requirements
Methods always get their parameters through the parameter class/structure/union (defined in TEclass_func.h, which to use (eg union/struct/class) is up to a coder) or void. Even more so - it must happen via a pointer to such structure/object/union.
Methods always return a pointer to an object or union(also defined in TEclass_func.h) or void - called result class.
Methods may in special cases use a pointer to a table as a parameter - but only in a case when there is only one parameter type. Otherwise a structure must be used.
The parameter/result class has all fields as public and may contain parameterless constructor(s)/destructor or parameterless methods - altho it is advisible that the parameter/result object was basicly a structure (ie - no methods and default constructor/destructor)
The parameter/result class is always named
parMethodName
resMethodName
eg we have a method called DoStuff should be declared
resDoStuff *DoStuff(parDoStuff *par);
IMPORTANT - one of the parameters in the parameter must be the adress of the result. (why? - to allow calling the functions with references to the result/parameter structures - thus save on memory allocation)
Exception:
Inline methods are exempt from above, however they must follow such rigors:
They must be private
They must be defined in the *.cpp of the class that will use them
They can use straight parameters and return them (no need for objects)
They can only be used in the *.cpp where they are defined.
4. Commenting
- Each source file starts with a table that shows:
Timestamp of the file
Author
And a neat TE ascii art logo
- before each method declaration the following data should be included:
what the method does
how the method does it
why this way of doing things was chosen
before each class field a description of what it is needed for must be provided (what it is used for, is it private, and if so why etc)
before each loop a description must be provided what happens - how does it happen and why
note:
for (int x=0;x<100;x++)
for (int y=0;y<100;y++)
{
}
is considered a single loop, but
for (int x=0;x<100;x++)
{
cout << "lol\n";
for (int y=0;y<100;y++)
{
}
}
is considered two seperate loops
Before ach condition a description must be provided what is being decided
note: the same rules as for loops apply
5. Error handling
Error handling is through exceptions throwing TeError class defined in TeError.h and TeError.cpp.
(note - take a look at the files below - it is the class in question. For now it only displays what happened and where. But we may expand it later).
The biggest change - i got rid of the variable naming standard. In action it only got things murkier.
Also - the requirement of each method be in a folder that mimics its position in a tree. Frankly because the class tree is actually a class graph.
For now each method just requires its own folder.
----
Transport Empire Coding Standard ver 3.0
1. Source naming and distribution
2. Class requirements
3. Method requirements
4. Commenting
5. Error Handling
--
1.
Source files pending inclusion to the project must obey following rules:
Only .h, .cpp and .txt files are allowed
.h - is for defining classes and structures
.cpp - is for implementation of methods
.txt - is a description of a class.
The rule is - each method has its own source file.
Naming goes as follows:
class definition is always
TeClass.h
method implementations are
TeClass_Method.cpp
constructor and destructor of a class are in
TcClass.cpp
method parameter structures are in
TeClass_Methodx.cpp
Ferinstance we have a class 'F00BAR' with methods 'DoStuff1', 'DoMoreStuff', 'DoRestOfTheStuff'
The files for these would look like this
TEF00BAR.h //definition of the class
TEF00BAR.cpp //constructor(s) and destructor
TEF00BAR_DoStuff1.h
TEF00BAR_DoStuff1.cpp
TEF00BAR_DoMoreStuff.h
TEF00BAR_DoMoreStuff.cpp
TEF00BAR_DoRestOfTheStuff.h
TEF00BAR_DoRestOfTheStuff.cpp
Each class is stored in a folder named after it - eg TEF00BAR is stored in TEF00BAR folder.
2.
A class has to have the following static fields:
std::string Author = 'author'; // a field containing a string with the author of the class (eg Uzurpator)
std::string Name = 'classname'; // a field containing the name of the class (eg Terrain)
std::string Abbreviation = 'class name short; // a field containing 4 letter abbreviation of the class (eg Tern)
long int Count; // a field contaning information how many instances of the class are there currently;
long int Version; // unix time stamp of the date the file was uploaded
char Status; // status of the class: accepted, beta, alpha, final etc.
class field names are built in this manner
prefix_Varname_suffix
prefix and suffix are up to the coder (eg - a coder may, or may not choose to use them).
Varname is a string that should describe as a noun with adjectives.
3. Method requirements
Methods always get their parameters through the parameter class/structure/union (defined in TEclass_func.h, which to use (eg union/struct/class) is up to a coder) or void. Even more so - it must happen via a pointer to such structure/object/union.
Methods always return a pointer to an object or union(also defined in TEclass_func.h) or void - called result class.
Methods may in special cases use a pointer to a table as a parameter - but only in a case when there is only one parameter type. Otherwise a structure must be used.
The parameter/result class has all fields as public and may contain parameterless constructor(s)/destructor or parameterless methods - altho it is advisible that the parameter/result object was basicly a structure (ie - no methods and default constructor/destructor)
The parameter/result class is always named
parMethodName
resMethodName
eg we have a method called DoStuff should be declared
resDoStuff *DoStuff(parDoStuff *par);
IMPORTANT - one of the parameters in the parameter must be the adress of the result. (why? - to allow calling the functions with references to the result/parameter structures - thus save on memory allocation)
Exception:
Inline methods are exempt from above, however they must follow such rigors:
They must be private
They must be defined in the *.cpp of the class that will use them
They can use straight parameters and return them (no need for objects)
They can only be used in the *.cpp where they are defined.
4. Commenting
- Each source file starts with a table that shows:
Timestamp of the file
Author
And a neat TE ascii art logo
- before each method declaration the following data should be included:
what the method does
how the method does it
why this way of doing things was chosen
before each class field a description of what it is needed for must be provided (what it is used for, is it private, and if so why etc)
before each loop a description must be provided what happens - how does it happen and why
note:
for (int x=0;x<100;x++)
for (int y=0;y<100;y++)
{
}
is considered a single loop, but
for (int x=0;x<100;x++)
{
cout << "lol\n";
for (int y=0;y<100;y++)
{
}
}
is considered two seperate loops
Before ach condition a description must be provided what is being decided
note: the same rules as for loops apply
5. Error handling
Error handling is through exceptions throwing TeError class defined in TeError.h and TeError.cpp.
(note - take a look at the files below - it is the class in question. For now it only displays what happened and where. But we may expand it later).
- Attachments
-
- TeError.cpp
- (503 Bytes) Downloaded 196 times
-
- TeError.h
- (946 Bytes) Downloaded 190 times
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
-
- Transport Empire Developer
- Posts: 699
- Joined: 03 Feb 2003 09:30
- Location: Back at the office
Feel free to contact me over Email! My current timezone: Europe/Amsterdam (GMT+1 or GMT+2)
[ General TE Discussion ] [ TE Development ] [ TE Coding ]
Under construction...
Code: Select all
+------------Oo.------+
| Transport Empire -> |
+---------------------+
Under construction...
Who is online
Users browsing this forum: No registered users and 20 guests