Difference between revisions of "Sive"

From CDOT Wiki
Jump to: navigation, search
(Project Marking Percentage)
(Coding Rules)
Line 60: Line 60:
  
 
== Coding Rules ==
 
== Coding Rules ==
 +
Please implement the following rules in all code that is a part of any project that this team(Sive) will undertake. And please feel free to add/modify the contents; however, you must make a note of changes in the summary so others will know.
 +
 +
=== Indentation and spacing ===
 +
 +
* Tabs and indentation of code will be 3 spaces
 +
* Leave a blank line in between functions and blocks of code
 +
* Brackets will be in the following format
 +
eg.
 +
MyFunction(){
 +
    // code
 +
}
 +
 +
=== Naming convention and Structure ===
 +
 +
* All Names must be meaningful(loop counters are excluded), the key is readability
 +
* Pascal case for functions/methods eg. GetData();
 +
* Camel case for variable names eg myData;  my_Data; weeklySalary;
 +
* Constants must be in all CAPS eg. PI
 +
* One variable declaration per line.
 +
eg.
 +
int i; // outer for loop counter
 +
int j = 0; // inner for loop counter
 +
double area; // holds the area of a square
 +
 +
* Pointer declaration
 +
int* myData; // pointer to data of type int, that holds the number students on record
 +
char* studentName; // pointer to data of type char, that holds the student name.
 +
 +
=== Commenting ===
 +
 +
* All variables MUST have a comment at declaration to indicate what they are, NON negotiable.
 +
* All Functions/methods comments MUST include the parameters it accepts and the return value it returns.
 +
* Comment blocks of code and whenever it is helpful for other programmers/NON-programmers to understand the code.
 +
* Use // for line commenting and /* */ for continuous multi-line commenting
 +
 +
=== Commits and Merging of code ===
 +
 +
* Under no circumstance will anyone directly push to master.
 +
* All code must be reviewed by another programmer before it can be merged to development or master branch.
 +
* Commits must have a comment to indicate what the changes are for.
 +
 
== meetings ==
 
== meetings ==
 
* latest will be on top
 
* latest will be on top

Revision as of 16:16, 4 November 2012


OOP344 | Weekly Schedule | Student List | Teams | Project | Student Resources


OOP344 | Weekly Schedule | Student List | Teams | Project | Student Resources

Sive

Project Marking Percentage

  • due in November 9th (Friday)

Group work:      40%        (25 <= xx <= 50)
Individual work: 60% +      (50 <= xx <= 75) 
-------------------------
Total           100%

Repository

  • repo Github id:

Team Members

Sive
First Name Last Name Section Seneca Id wiki id IRC nick GITHUB ID Blog URL
Zhenyang Chen A zchen91 Zhenyang Chen crans crans Leash
Shuming Lin B slin44 Shuming Lin kevin000 kevin000 intermerdiate C++
Xin Li A xzli2 Xin Zhu Li XinZhu xinzhu OOP344
Junzhuo Ren B jren22 Junzhuo Ren vincent9527 renjunzhuo Vincent's Blog
Donghu Zhang A dzhang50 Dong donghu donghu MaC

Issues and Status

1.1_AddConsoleClass

  • Assigned to: Donghu
  • Code review by: Donghu
  • Status:
    (being developed)
  • comments:

2.8.1_AddTextClass

  • Assigned to: Donghu
  • Code review by: Donghu
  • Status:
    (being developed)
  • comments:

2.8.2_AddCTextClass

  • Assigned to: Donghu
  • Code review by: Donghu
  • Status:
    (being developed)
  • comments:

Coding Rules

Please implement the following rules in all code that is a part of any project that this team(Sive) will undertake. And please feel free to add/modify the contents; however, you must make a note of changes in the summary so others will know.

Indentation and spacing

  • Tabs and indentation of code will be 3 spaces
  • Leave a blank line in between functions and blocks of code
  • Brackets will be in the following format

eg.

MyFunction(){
   // code
}

Naming convention and Structure

  • All Names must be meaningful(loop counters are excluded), the key is readability
  • Pascal case for functions/methods eg. GetData();
  • Camel case for variable names eg myData; my_Data; weeklySalary;
  • Constants must be in all CAPS eg. PI
  • One variable declaration per line.

eg.

int i; // outer for loop counter
int j = 0; // inner for loop counter
double area; // holds the area of a square
  • Pointer declaration
int* myData; // pointer to data of type int, that holds the number students on record
char* studentName; // pointer to data of type char, that holds the student name.

Commenting

  • All variables MUST have a comment at declaration to indicate what they are, NON negotiable.
  • All Functions/methods comments MUST include the parameters it accepts and the return value it returns.
  • Comment blocks of code and whenever it is helpful for other programmers/NON-programmers to understand the code.
  • Use // for line commenting and /* */ for continuous multi-line commenting

Commits and Merging of code

  • Under no circumstance will anyone directly push to master.
  • All code must be reviewed by another programmer before it can be merged to development or master branch.
  • Commits must have a comment to indicate what the changes are for.

meetings

  • latest will be on top
  1. topic and date1
  2. topic and date2

discussions

  • ......