Team !YOU - Discussions

Team !You - To the main team page.

Official Standards - Go to team's official programming standards.

Open Discussions

Current open discussions

Committing Practices

When many people work together on the same project, ideally only a couple of them are responsible for committing the code. Although our team has only 8 members, it is probably a good idea to give the committing responsibility to only one or two members at once. Fardad has suggested that we rotate this responsibility, and I think we should try that. To make it possible, I have thought of a way to make it work.

• Each week two of us are responsible for committing. The order we alternate this role could be random, or we could go down the team member list as we did for dividing the simple functions among us.

• Join our IRC room before committing. Even with svn's merging capabilities, it is easier if two people can talk to each other if they happen to be committing at the same time.

• If you finished something in your branch that is worth committing but it's not your turn to commit yet, create a discussion on this page with your name and the files you worked on. That way we can all check your work on your branch and comment possible changes here. Once everyone has looked at it, one of the committers can finish the job.

• Always document your commits, so we have some control in case something goes wrong.

Please add you comments to this suggestion.

Committing Agreement

Here is the result of discussion on "Committing"

1. How often
   • Every Monday that we have our weekly IRC meeting, those people who are in charge of committing for that week,will be in the meeting to make sure there isn't anything wrong with the codes and will commit them right away.
2. Who
   • We will go by the order of the team's member list. Every week, 2 members are responsible for committing.
3. How
   • Those people that are done with their part of code, will upload their code with their name and their files in this page[] and will let everybody else know that they have finished - in case somebody wanted to comment any changes.

Old Discussions

IRC Meeting Discussion

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.
Timothy	Any evening or weekend is good for me. Most school days I'm home by 6:30 p.m. at the latest so anytime after that would be perfect.
Mddaniels	Evenings are good for me, I have a paper route that keeps me busy until 7pm on Tuesdays and Thursdays but asside from that I'm available
Nsimmalavong	Anytime after 7 pm is good except on Tuesdays and Fridays, it would be preferred after 9 because I tend to work later those days. I can be made available at anytime on IRC outside those times if needed.
Amward1	Evenings are good.

Team !You Programming Standards Discussion

(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!"); } }
Timothy	What I do in Visual Studio is change the indentation settings to input 2 spaces instead of tabs, and I prefer it this way just in case there is a situation where multiple nested code is required and it's not all running off the page to view it properly.
Mddaniels	I myself have always used the tab just for speed and ease of programming, plus I like having my code spaced out so that I can locate blocks of code better. But if the general opinion is to use two spaces then I will modify the visual studio software to use two spaces.
Nsimmalavong	As most of you have said, I also use 2 spaces as indentation. Along with fmDeOliveira, I've put a blank line to separate blocks of code

(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.
Mddaniels	I agree with option one, there are plenty of times when you need the counters saved for use later in the function.
Nsimmalavong	Agreed with fmDeOliveira, I prefer option 2 the same reasoning. Having amibiguous variables floating around can get confusing and we may just end up needing more than what the 26 letter alphabet provides (which results in some unique variables like a13). If the variable is needed after the loop, it should be copied into another variable before the end of loop

(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
Mddaniels	Defines should always be caps, and camel notation is very good, just as long as the variable names make sense I'll be happy. I got sick and tired of last semester's group giving variable names like "ptr".

(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.
Mddaniels	What you need to remember is that we are coding in C the // for single line comments does not work in C. All coments need to be in the /* */ format. Also try and use the comments to reflect the Art of Programming. Code should be written that any programmer can look at the code and understand what is going on.

(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(",");
 }

Mddaniels example: This is how I was taught in IPC144 by Murray Saul

 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.
Mddaniels	I agree with option 2. Although I am used to coding my braces on seperate lines, see my small example above.