Table of Contents

Tasks

determining schedule

Logging effort

Coding Standards

Professional's Opinion

Google's Opinion

Windows Folders

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.

SVN

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 

 %APPDATA%\Subversion

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

GitLab

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

Versioning

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.

Sample 

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
    function(
              param1,
              param2
            )
    {
        functionCall(
            param1,
            param2
        );
        code;
    }

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

Example 

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"

Tools