Team Coding Standards

Naming Conventions

• No underscores should be used in naming anything

File Names

All files should be named just as the class within them is named (See below for class types)

• Commands: camelCase
• Subsystems: PascalCase

Folder Names

All folders should be named in camelCase
WARNING: Do not rename ANY folders, it will break Master!

Subsystems

All subsystems must be named using PascalCase
WARNING: Do not rename ANY files, it will break Master!

Commands

All commands must be named using camelCase, starting with a lowercase letter WARNING: Do not rename ANY files, it will break Master!

• Commands should also be placed in a folder pertaining to their subsystem
  • These folders should be named with the same name as the subsystem

Variables

All variables not pertaining to the ones above, should be written in camelCase, starting with a lowercase letter Constant variables should start with "k", and proceed to be PascalCase after

Methods

Constructor methods must be the same name as the class All other methods must be camelCase starting with lowercase

Enums

All enums must be PascalCase

Privacy Settings

Classes (Subsystems/Commands)

All classes should be public so every class can be accessed from another

Variables

Variables within a subsystem or command should be kept private, unless a condition requires it to be public. Reason being, not every class needs to have access to these variables.

Methods

All methods will be public, or protected, as they will most likely be used outside of the class

• Methods should also be written in the subsystem files

Default Commands

Subsystems do not require a default command, thus it is unnecessary to use a default command for every subsystem, unless your code needs it.

Formatting

When instantiating a variable, group together variables with the same variable/object type and privacy settings

Example:

public int x;

private int id;

private double speed;

Java Docs / Comments

All methods MUST have java docs
All commented out lines should have a single line comment to mark that the code was being used before
All extra comments should be written in blocks

Examples:

/**
 * Javadocs documentation goes here 
 * @param var - describe your variable and an example of the value range
 * @return - describe what the method is returning and what value range you should recieve
 */
public inttest(int var) {
 //var++;     --This code WAS being used, but is commented out for reference, it should be removed before merging with 
master
  /*
   * This code adds 2 to var
   */
  var+=2;
  return var;
}

## Authoring Files
Every class will be authored by the person who <strong>WROTE</strong> the class. 
(If you added a few lines to the file, doesn't mean you wrote it)
The @author statement 

## GitHub Standards
- Branches should only be made when a different subsystem is being worked on
- Reuse branches when working with a subsystem that already has a branch made for it. 
-