Coding standard

Archived discussions related to Transport Empire. Read-only access only.

Moderator: Transport Empire Moderators

Grunt
Route Supervisor
Route Supervisor
Posts: 449
Joined: 03 Oct 2003 20:22
Location: Edmonton, Alberta
Contact:

Post by Grunt »

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.
...
Why do these need to be variables? They belong in the header of the source, not in memory space while the program is running.
Grunt
(aka Stephan Grunt, CEO of Grunt Transport Inc. since 1994.)
User avatar
uzurpator
Transport Empire Moderator
Transport Empire Moderator
Posts: 2178
Joined: 10 Jan 2003 12:21
Location: Katowice, Poland

Post by uzurpator »

Grunt:
Grunt wrote:..which makes for one more directory level you have to traverse when looking for the source file you need to work with.
Which makes it more troublesome to open a file, which you do one time.
Most text editors have find features for exactly this reason.
Ctrl+F,type what you seek,enter vs doing nothing (or alt-tabbing)
or
Click on the class,ethod tree vs doing nothing (or alt-tabbing)

I say it's an improvement
..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.
It will.

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.
...in the file of the associated class, of course.
Line 124? 274? Before/after class b? This is small stuff, but important in the convinence of the work.
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.
Version control requires maintenence on each change of the code. Splitting *.cpp and *.h at 1 per method does not.

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);
};
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?
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.
Hellfire
Transport Empire Developer
Transport Empire Developer
Posts: 699
Joined: 03 Feb 2003 09:30
Location: Back at the office

Post by Hellfire »

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:
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:
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:The parameter/result class is always named

parMethodName
resMethodName

eg we have a method called DoStuff should be declared

resDoStuff *DoStuff(parDoStuff *par);
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:

Code: Select all

for (int x=0;x<100;x++)
  for (int y=0;y<100;y++)
    {
    }
is considered a single loop, but

Code: Select all

for (int x=0;x<100;x++)
  {
  cout << "lol\n";
  for (int y=0;y<100;y++)
    {
    }
  }
is considered two seperate loops
I don't see the point in mentioning this difference, but the place of the curly braces is strange, in my opinion.

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;
}
But I don't have any problems with

Code: Select all

for(int x=0; x<100; x++)
{
    a[x]=0;
}
So basically, my preference sums up to:
  • I like to have the closing brace ( } ) on the same indentation level as the accompanying command
  • I prefer having spaces around binary operators
Of course, in the end I will comply to the indentation defined in the coding standard, whichever form that might be. :)

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)

Code: Select all

+------------Oo.------+
| Transport Empire -> |
+---------------------+
[ General TE Discussion ] [ TE Development ] [ TE Coding ]
Under construction...
User avatar
uzurpator
Transport Empire Moderator
Transport Empire Moderator
Posts: 2178
Joined: 10 Jan 2003 12:21
Location: Katowice, Poland

Post by uzurpator »

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

Code: Select all

struct resDoStuff
  {
     int field1;
     int field2;
     int field3;
  };

struct parDoStuff
  {
    int field1;
    int field2;
    int field3;
  };

resDoStuff *DoStuff(parDoStuff *params);
They are just to avoid situations where you have methods that look like this

Code: Select all

var = func(1,3,object->method2(5423)4,5,pointer->struct->pointer.tab,1774.22,func2(4322));
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.
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.
User avatar
uzurpator
Transport Empire Moderator
Transport Empire Moderator
Posts: 2178
Joined: 10 Jan 2003 12:21
Location: Katowice, Poland

Post by uzurpator »

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! :)
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.
User avatar
uzurpator
Transport Empire Moderator
Transport Empire Moderator
Posts: 2178
Joined: 10 Jan 2003 12:21
Location: Katowice, Poland

Post by uzurpator »

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?
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.
fujitsu
Engineer
Engineer
Posts: 32
Joined: 12 Jul 2005 08:14
Location: Melbourne suburbs, Victoria, Australia (GMT+10)

Post by fujitsu »

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?
Firstly, Pong!

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.
Hellfire wrote: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;
}
But I don't have any problems with

Code: Select all

for(int x=0; x<100; x++)
{
    a[x]=0;
}
So basically, my preference sums up to:
  • I like to have the closing brace ( } ) on the same indentation level as the accompanying command
  • I prefer having spaces around binary operators
Of course, in the end I will comply to the indentation defined in the coding standard, whichever form that might be. :)
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.

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.
fujitsu
Engineer
Engineer
Posts: 32
Joined: 12 Jul 2005 08:14
Location: Melbourne suburbs, Victoria, Australia (GMT+10)

Post by fujitsu »

Hello? People, it has been four days since I posted... And nobody had posted in the Coding forum since then. This is a Bad Thing(tm). Is anybody out there!!??

William.
User avatar
uzurpator
Transport Empire Moderator
Transport Empire Moderator
Posts: 2178
Joined: 10 Jan 2003 12:21
Location: Katowice, Poland

Post by uzurpator »

I'm still here. but my patience grows weak...
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.
Mek
TTDPatch Developer
TTDPatch Developer
Posts: 417
Joined: 13 Apr 2004 13:35
Location: Eindhoven, Netherlands
Contact:

Post by Mek »

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.
User avatar
uzurpator
Transport Empire Moderator
Transport Empire Moderator
Posts: 2178
Joined: 10 Jan 2003 12:21
Location: Katowice, Poland

Post by uzurpator »

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

Code: Select all

TEclass.h
method implementations are

Code: Select all

TEclass_methodx.cpp
constructor and destructor of a class are in

Code: Select all

TEclass.cpp
method parameter structures are in

Code: Select all

TEclass_methodx.cpp
Ferinstance we have a class 'F00BAR' with methods 'dostuff1', 'domorestuff', 'dorestofthestuff'
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
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:

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.
class field names are built in this manner

Code: Select all

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:

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

Code: Select all

parMethodName
resMethodName
eg we have a method called DoStuff should be declared

Code: Select all

resDoStuff *DoStuff(parDoStuff *par);
The parameter/result class must have static field called

Code: Select all

int Version;
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 :D

- 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++)
    {
    }
is considered a single loop, but

Code: Select all

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
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.
User avatar
DominionSpy
Tycoon
Tycoon
Posts: 1429
Joined: 03 Oct 2003 23:59
Location: Lancashire, UK
Contact:

Post by DominionSpy »

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?
I've been away in Spain for 10 days, so I wasn't able to reply.

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.
Image
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.
User avatar
uzurpator
Transport Empire Moderator
Transport Empire Moderator
Posts: 2178
Joined: 10 Jan 2003 12:21
Location: Katowice, Poland

Post by uzurpator »

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.
Yet you still failed to provide why single file is superior to multiple files.
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.
cout << obj->author;

Mek/n Uzurpator/n Mek/n DominionSpy/n

You can write a whole book there...
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.
No info is ever useless
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).
Good point about the method locals. I'll add them to the next revision of the standard.
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.
1. To prepare the parameter object you need to make a consious effort - so you will never forget what a parameter does.
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);
Section 4: Again I think the Author is unnecessary. Otherwise it sounds good.
Author is static - and provides info - we can strip it in final versions though (conditional compile)
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.
User avatar
PJayTycy
Route Supervisor
Route Supervisor
Posts: 429
Joined: 09 Mar 2004 20:30

Post by PJayTycy »

seems good, except for the variable naming conventions...
On holiday from 16/07 till 31/07
User avatar
uzurpator
Transport Empire Moderator
Transport Empire Moderator
Posts: 2178
Joined: 10 Jan 2003 12:21
Location: Katowice, Poland

Post by uzurpator »

PJayTycy wrote:seems good, except for the variable naming conventions...
What you propose then?
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.
User avatar
DominionSpy
Tycoon
Tycoon
Posts: 1429
Joined: 03 Oct 2003 23:59
Location: Lancashire, UK
Contact:

Post by DominionSpy »

uzurpator wrote:
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.
Yet you still failed to provide why single file is superior to multiple files.
Actually I said this:
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.
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'.

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.
uzurpator wrote:
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.
No info is ever useless
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'.

PS I don't whether it's just a communication problem, but it seems to me like you're taking these comments personally.
Image
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.
User avatar
uzurpator
Transport Empire Moderator
Transport Empire Moderator
Posts: 2178
Joined: 10 Jan 2003 12:21
Location: Katowice, Poland

Post by uzurpator »

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.
I understand your concerns.

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.
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'.
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?
PS I don't whether it's just a communication problem, but it seems to me like you're taking these comments personally.
Well - I'm a rather blunt person - and considering that english is not my native language... it may come up in very bizarre ways ;)

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.
User avatar
uzurpator
Transport Empire Moderator
Transport Empire Moderator
Posts: 2178
Joined: 10 Jan 2003 12:21
Location: Katowice, Poland

Post by uzurpator »

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 :D

- 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 191 times
TeError.h
(946 Bytes) Downloaded 184 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.
User avatar
Hyronymus
Tycoon
Tycoon
Posts: 13233
Joined: 03 Dec 2002 10:36
Location: The Netherlands
Contact:

Post by Hyronymus »

Just a small point of concern: I read coding already started in the roadmap topic but is this coding standard already accepted?
Hellfire
Transport Empire Developer
Transport Empire Developer
Posts: 699
Joined: 03 Feb 2003 09:30
Location: Back at the office

Post by Hellfire »

Coding standard overruled.

Continue here.

EDIT: a final coding style has been chosen (15112006).
Feel free to contact me over Email! My current timezone: Europe/Amsterdam (GMT+1 or GMT+2)

Code: Select all

+------------Oo.------+
| Transport Empire -> |
+---------------------+
[ General TE Discussion ] [ TE Development ] [ TE Coding ]
Under construction...
Locked

Return to “Transport Empire Development Archive”

Who is online

Users browsing this forum: No registered users and 6 guests