Team !YOU - OOP344

This is Team !YOU's Project Page

You will find all project related information here

Team Members

OOP344 - 2010 Team !YOU

Last Name	Name	Seneca ID	Section	Blog URL	IRC nick	My Contributions
Adams	Matthew	mdadams1	A	http://www.tandemwebdesign.ca/blog	MattAdams	Contributions
Catibog	Timothy	tjcatibog	A	http://tjprogramming.blogspot.com/	tjcatibog	Contributions
Daniels	Matthew	mddaniels	A	http://cdnpadawan.wordpress.com/	CDNPadawan	Contributions
De Oliveira	Felipe	fmdeoliveira	A	http://feliploko.wordpress.com/	fmDeOliveira	Contributions
Misko	Andrew	ammisko	A	http://ammisko.blogspot.com	ammisko	Contributions
Simmalavong	Niki	nsimmalavong	A	http://oop344-niki.blogspot.com/	nsimmalavong	Contributions
Ward	Amy	amward1	A	http://amward1.wordpress.com/	award	Contributions
Ziaei	Minoo	mziaei1	A	http://minooz.wordpress.com/	Minooz	Contributions

IRC

Our IRC channel is #oop344_!you on freenode. Please join the channel whenever you are on IRC.

IRC Meetings

We need to decide when we should have our meetings.

Discussion

Name	Comment
fmDeOliveira	Evenings work better for me... It is hard to find some time in the morning or afternoon that all or most of us are able to be on IRC.
ammisko	Evening are also good for me. I don't have class later than 320 every day. As long as I know a few days in advance I shouldn't have a problem with meeting any time after 320.
MattAdams	Evening is probably better, because that is when I do all of my programming. I normally work from Thursday to Sunday, so early week is better for me.
Mziaei1	Evenings are better for me too. Any evening, unless something unexpected happens.

Team Programming Standards

An area for listing our teams programming standards that we will use when constructing the project. Please follow these rules when writing code for this project. This will make it easier for us to help each other and collaborate in the whole process.

Declare only one variable in each line.

This makes it easier to scan the code and find the type of a variable that you see somewhere else in the code.

Do:

 int a;
 int b = 0;
 int c = a;

Don't:

 int a, b = 0, c = a;

Do not use tabs when indenting.

The tab space is interpreted different across different software and operating systems. Use normal spaces to add indentation instead.

(Discussion: Indentation)

Something simple, but that should be standard for all pieces of the code.

Discussion

Name	Comment
fmDeOliveira	I usually put two spaces for a new indent, and keep a blank line between new big blocks of code and whatever comes before it (usually an if statement, a for loop, or the signature of a function).
MattAdams	Please only indent to 4 spaces. If we all use the same indenting, when it comes to putting our code together it will looks the same. NOTE: Most text editors have the option to change tabs to spaces, so you are still able to press the tab key, however it will convert it to spaces when the file is saved.
Mziaei1	I actually agree with 2 spaces more than 4 spaces. There was an example here before!! main() { for (i = 0; i <10; i++) { printf("Hi!"); } }

Put the pointer identifier(*) right after the target variable type.

Pointers are hard enough to deal with. It only makes it more complicated if they are declared differently throughout the code.

Do:

 int* p1;
 char* p2;

Don't:

 int *p1;
 char *p2;

(Discussion: Use of iterating variables on for loops)

There are two major ways of dealing with the iteration variable on for loops. We should come to a consensus on how to deal with it on our project.

Option 1: Declare the variables outside the loop; initialize them inside the loop; keep their exit values for future use.

 int i;                                // counter
 for (i = 0; i<5; i++) printf(".");    // Prints .....
 printf("%d",i);                       // Prints 5

Option 2: Declare and initialize variables inside the loop; lose the variable at the end of the loop scope;

 for (int i = 0; i<5; i++) printf("."); // Once the loop is done, variable i cannot be accessed anymore.

Discussion

Name	Comment
fmDeOliveira	I definitely prefer option 2. It is much easier to keep recycling the loop variables without having to worry if they already exist or not. In case we need the value of the loop variable after the loop is done, we should just copy it to another variable before the end of the loop.
ammisko	I like option 1 better (I changed it a bit). I think it looks cleaner and is much easier to read for someone who doesn't know what the code does (especially with comments). Also what if we need to use a loop variable from outside the for loop? Or if we need to use the first part of the for-loop for other code? Option 1 could accommodate that better I think.
MattAdams	I like both ways. I use option1 when I need to use the counter for something else. And I use option2 when I need to right a quick for loop. As for a standard, I think option1 should be used, that way all of the variables are declared at the top of every function, and that way we don't have to copy the counter to another variable.

(Discussion: Variable names)

How should we name the variables that we create on our project?

Discussion

Name	Comment
fmDeOliveira	I suggest we avoid abbreviations, since what might be obvious for some could be confusing for others. Full words or short expressions could be used where the first letter is always lower case, and the first letter of the following words are upper case. Examples: cost, totalPrice, numberOfPeople.
MattAdams	I also agree w/ Felipe. Using Camle notation is a nice and easy way to name variables. However, I would have said numOfPeople, instead of 'numberOfPeople'. As for #define goes. Use UPPER case, and separate words by the underscore(_). ie. #define ISBN_LENGTH, #define AREA_MAX, #define MAX, #define LENGTH

(Discussion: Use of comments)

When should we use double slash (//) and when should we use slash-asterisk (/* */)?

Discussion

Name	Comment
fmDeOliveira	I prefer using // for single-line comments and /* */ for blocks of commented code. This would avoid problems commenting out blocks of code that already have single-line comments (the end of the single-line comment would not be interpreted as the end of the block comment).
MattAdams	I also like using // for end of the line comments to slitly explain whats going on, and use /* */ for commented out code, as well as explaining a certain block of code that is confusing to understand.

(Discussion: Nesting)

How do we deal with else statements?

Option 1: else right after the end of the if block

 if (a > 0) {
   printf(".");
 } else {
   printf(",");
 }

Option 2: else on a line below the end of the if block

 if (a > 0) {
   printf(".");
 }
 else {
   printf(",");
 }

Discussion

Name	Comment
fmDeOliveira	I prefer option 2.
MattAdams	Option 2 all the way.
Mziaei1	Agree with option 2.