determining schedule

  • Short - Less than a week ( a day or 2)
  • Medium - 1 week
  • Long - +2 weeks
  • Suxly - Unknown. this is considered a hard task.

Logging effort

  • use the comment you put in svn to comment the work you did for a given task.
  • 95% complete means that you are done and the task needs to be reviewed
  • 90% complete means that the task has some rework that needs done
  • 100% complete means that the task is done but this can only be set by the manager.

Coding Standards

Version Control

Always supply a comment when committing code to the repository. Make sure it describes what you have changed since the last commit.

Commit code on a daily basis unless people are conducting tests. If testing is in progress, only commit code that is functioning. If you need to commit on a daily basis then create a branch then merge the branch back in to the truck when it is functioning.


Help on how svn works behind a proxy:

Eclipse: http://tabaquismo.freehosting.net/ignacio/eclipse/tortoise-svn/subversion.html

You will need svn for command line which is availible through collabnet. Once installed on a windows machine, navigate to


There are two files config and servers. The servers file contains the settings for the proxy. On a side note, you may want to configure the config file to only accept file types that are allowed into the repository.

Files that are not allowed:

*.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo *.rej *~ #*# .#* .*.swp .DS_Store *.ncb *.suo Debug* Release* *.user bin obj build out


May want to switch to GitLab. It integrates everything I've setup and configured with dokuwiki/svn


This outlines how version numbers work.

x.x[letter] Alpha/Beta

The first x represents an official release of the product.

The second x represents an incremental test build of the product. The second x is a stand alone number, i.e. when it is a 9 and it goes to 10 then the version would look like 1.10 as to 1.1

The letter represents a released patch. This is an increment from a-z. The patch will be reset when the second value is incremented. Patches are considered quick fixes.

Alpha will denote that the product is ready to release pending offical approval.

Beta is that the product is released but still considered unstable.

Comment Format

Use the document method of the language you are developing in. Comment Files, Classes, Functions, and variables using the standard format below. Change the tags to support your documentation tool. Also, comment anywhere in the logic where it would take you a few minutes to figure out what the code section does. The Doc generator maybe of question. They seem to be IDE specific. To use one across all might pose a challenge. Also, IDEs would loose some features of their own document system. If a universal doc generator is desired, this needs to be discussed amongst the group.

For Java use JavaDoc

For C# use XML

Alt For C# use XML

For PHP use

For ActionScript similar to Java

For HTML use

For JavaScript use

Standard comment blocks:

/// File: name
/// <author></author>
/// <version></version>
/// <summary></summary>

/// Class: name
/// <author></author>
/// <version></version>
/// <summary></summary>

/// Function: name
/// <summary></summary>
/// <param>name: Description.</param>
/// <returns>Returns 0 for a success. Otherwise the
/// value will be in the error lookup table: <see></see>
/// </returns>

/// Variable: name
/// <summary></summary>

For status comments, Add a descriptive comment for what needs to be done:

for code that needs to be created.

// TODO : 

for code that is broke or doesn't do as expected.

// FIX : 

other optional status tags are as follows:

// HACK :
// DEBUG :

These TODO and FIX comments should stay but just remove the tag once the code has been written or fixed.

Code Format

Spacing will be 4 spaces for tabs. If your editor supports it, which most do, change your tabs to spaces and make sure it is 4. For a single file of code always put variables first, then helper functions then execution functions. This goes for classes as well. Contructors and destructors and other class specific functions should come before member functions. As for classes this should be one class to one file.


class ClassName
    // Constant Variable declerations
    static int VAR_WITH_SPACES;

    // Public Variable declerations
    int m_VarNoSpaces;

    // Protected Variable declerations
    int m_VarNoSpaces;

    // Private Variable declerations
    int m_VarNoSpaces;

    // Constructors & Destructors

    // Public Member Functions

    // Protected Member Functions

    // Private Member Functions

Naming Conventions

The names of any part of code should be descriptive. They should be camel cased. Underscores should be used to separate between type and name. All names should contain the type. Abbreviations are ok if they can be understood by more than one person. Constants are all caps with underscore for spaces.


CONSTANT_VAR // constant var
m_Var // class var
var // local var
ptr_Var // local pointer
jtf_NameOfUser // Gui var in this case it's "java text field"


design/coding_standards.txt · Last modified: 2020/11/19 14:21 by
Back to top
CC Attribution-Share Alike 4.0 International
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0