Team B - OOP344 20133

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

Team B: BDOT

First Name	Last Name	Section	Seneca Id	wiki id	IRC nick	Blog URL
Arlene	Lee	C	alee110	Arlene Lee	Zephyr135	KakuKaku
Adam	Sharpe	B	ansharpe	Adam Nicholas Sharpe	AdamSharpe	Object Oriented Programming Stuff
Ragu	Sivanandha	B	rsivanandha	Raguraam Sivanandha	Ragu	Ragu's Blog
Benson	Wong	B	bwong53	Benson Wong	wongbsn	Benson's Blog

Repository

BDOT Repository Path: Team B

Master Branch Status

 FREE

Tasks

Release 0.4

1. Prototyping
   • Member: Benson Wong
   • Task: Create prototypes and empty definitions for all classes
   • To be completed by: November 14, 2013
   • Status: Complete
     
     
2. CButton
   • Member: Arlene Lee
   • Task: Code cbutton.h and cbutton.cpp
   • To be completed by:
   • Status: In Progress
     
     
3. CValEdit
   • Member: Adam Sharpe
   • Task: Code cvaledit.h and cvaledit.cpp
   • To be completed by:
   • Status: In Progress
     
     
4. CCheckMark
   • Member: Benson Wong
   • Task: Code ccheckmark.h and ccheckmark.cpp
   • To be completed by:
   • Status: Complete
     
     
5. CMenuItem
   • Member: Ragu Sivanandha
   • Task: Code cmenuitem.h and cmenuitem.cpp
   • To be completed by:
   • Status: In Progress
     
     

Release 0.3 is due Nov 4th, 23:59

1. Prototyping - 16%
   • Member: Adam Sharpe
   • Task: Create prototypes and empty definitions for all classes
   • To be completed by: October 19, 23:59
   • Status: Complete
     
     
2. CLabel - 17%
   • Member: Ragu Sivanandha
   • Task: Code clabel.h and clabel.cpp
   • To be completed by: October 22, 23:59
   • Status: Complete
     
     
3. CDialog - 50%
   • Member: Arlene Lee and Adam Sharpe
   • Task: Code cdialog.h and cdialog.cpp
   • To be completed by: October 31, 23:59
   • Status: Complete
     
     
4. CLineEdit - 17%
   • Member: Benson Wong
   • Task: Code clineedit.h and clineedit.cpp
   • To be completed by: October 29, 23:59
   • Status: Complete
     
     
5. Optimization and Testing
   • Member: Adam, Arlene, Ragu, Benson
   • Details: Improving code efficiency, implement short circuit evaluation (for Fardad), and testing for bugs
     
     

Release 0.2 is due October 20th, 23:59

1. Organize and complete team page - Complete
2. Select a team member's console.cpp and console.h to use - Complete
   • That team member should branch and clone repository and add the files to it as well as comment on cframe.h with github id, date, and time and merge it back
3. All other members clone the repository, comment, and test the execution of CFrame - Complete
   • The comment should include your github id, date, and time in the cframe.h file
   • Push the final changes to github

Meetings

November 13, 2013 - Media Pod 4

• Went over release 0.4 as a team over Skype and in the study room, will decide specific member roles and deadlines to finish each task on Monday, November 18, 2013

October 29, 2013 - Media Pod 4

• Finished up release 0.3

October 25, 2013 - Skype

• Discussion on coding issues and fixes for release 0.3

October 24, 2013 - Skype

• Discussion on coding for release 0.3

October 20, 2013 - Skype

• Deciding on member roles and organizing time associated with the completion of each task for release 0.3

October 16, 2013 - Rm S3011

• Completing team page, finalizing coding standards, and deciding on whose console.cpp/console.h we are using (Arlene's)

October 15, 2013 - Rm S3012

• Meet, greet, and discussion on coding standards

Tips & Important Notes

Here is a list of important notes listed within the project page

• Add recompilation safeguards to all your header files.
• Always use forward declaration if possible instead of including a class header-file.
• Use includes only in files in which the actual header file code is used, i.e. if strlen function is used only in cpp file then only include "bconsole.h" in this file.
• Avoid "just in case" includes.
• Each class MUST have its own header file and cpp file for implementation.
• Use the class name for the name of the file but make sure it is all lowercase.

  For example CFrame class should have cframe.h and cframe.cpp files for its implementation.

• Avoid placing using directives and declarations in header files, as this might lead to namespace conflicts since we do not know in which order a header file will be included within any other file (source: Chris Szalwinski, BTP300 readings on namespace design considerations)

Project Marking Percentage

 Group work:      40%
 Individual work: 60% +
 -----------------------
 Total:          100%

Coding Style and Standards

• The following will serve as an example of our coding standard:

#ifndef __BDOT_FILENAME_H__ // Our Team's Safeguard
#define __BDOT_FILENAME_H__


class example { // There will be a space after every class identifier for the definition
  public:
  int _data; // Member variables should start with an underscore
  int _arraySize // Use meaningful names for variables when applicable and use lower Camel Case
  int _width; // Every object have its own type
  char* _pArray; // Pointers should have * part of the type
  void display():
};

void example::display() { // There will be a space after every function identifier for the definition 
}

#endif

...

#include <iostream>
#include <cstring>
using namespace std;

int main() {
  int a = 0; // Indentation is 2 spaces
  int b = 1; // NO Tab characters allowed! Replace every tab character with 2 spaces.
  char name[] = "Spoom";
  // Put a newline after variable declaration
  if(a > b ? a : b) {
  a = a * b; // Put a space between EVERY variable and operator
  }
  // Put a newline after a control structure
  if(!strcmp(name, "Spoom")) {
  cout << "Welcome, Spoom!" << endl; // Every statement within a control structure will
  } // be wrapped in braces, even if there is only 1 line
  else { // Else statement will be on a newline after the If control structure
  cout << "Get out." << endl;
  }

  return 0;
}