Coding Procedures

When making changes to the code please follow these steps.

• Talk about your ideas with RBDEV before you write lots of code. Of course, this is not always necessary but it is often a good idea to get feedback.
• Do not remove or change the file headers or MPL licenses at the top any file. If you add totally new files, add the same file header and license atop them. Template headers for new files.
• When possible, make small commits instead of huge batched up changes. This just means that when some work is done commit it rather than batching it up with other work items.
• If you add or change RSL or robot capabilities add code to tester.prg to verify it.
• Before committing any code, do whatever you can to test it. You must be able to load and run tester.prg in a 500 game match without any errors. This is not enough, however. Stress your changes as much as you can in other ways before committing. Eventually I would like to create a suite of standard tests that include everything from functionality to performance.
• If you are unsure about your code have someone else review it or test it before committing.
• After you have committed your code, send an email to RBDEV with the following format:
  subject:  delta: what you did
  body:  changes: what did you did and why
         testing: what you did to make sure it works

Coding Style

Unfortunately RobotBattle code has very little style since it has been written over many years. I had no particular coding style when I started RB and have changed several times since then. These days I like the following basic style guideline. While not much of the code in RB matches this today, I am changing it slowly. The best example in RB is DDrawHelper. If people do not like part or all of this, bring it up on RBDEV.

• Avoid lines longer than about 80 columns.
• Indentations are four spaces. No tabs should be in the code. This sounds strange but experience has proven this a good policy. Tabs are handled poorly by many tools.
• Avoid Hungarian notation, except for some standard Windows things.
• Non K&R style aligned brackets. Like this:
  if( test == true )
  {
      // do something
  }
• Class, struct, and enum type names have every word capitalized:
  class SymbolTable
• Public member functions have each word capitalized. The first word is often a verb.
  bool GetValue( const char *varName );
• Private and protected member functions are prefixed with "_" .
  void _RecalcLayout( );
• Member variables should almost always be private. They are prefixed with "_" and the first word is not capitalized. Following words are capitalized. Public members also start with "_".
  bool _radarOn;
• Function arguments and stack variables follow the same convention as member variables, but do not start with "_".
• Global constants and #defines are in all CAPS. Words usually separated by "_"
  const int MAX_WIDTH = 30;
• Global variables follow the same convention as other variables but are prefixed with "g_"
  extern class CWinrob32App *g_winrobApp;
• Large comment blocks outside of function scope (such as function headers) are formatted as below. Comments inside functions use C++ style // comments, never /* */ comments. This allows for commenting out entire functions with /* */. All functions should have a header block even if the block is left empty.
  /*****************************************************************************
    comments go here
  *****************************************************************************/
• All files should start with the standard header text. You can cut-and-paste from headers.txt. Don't worry about fixing up the file names, CVS will update these when you commit the file.