Open main menu

CDOT Wiki β

OOP344 Temporary

Revision as of 10:52, 28 October 2009 by NorthWind87 (talk | contribs) (Comment Blocks OOP344 northWind87: changed file headers to make use of svn:keywords property)

Team Temporary Name

Group Contact/Team Leader: Hasan
Group Contact #2: Joseph Hughes

Last Name Name Seneca Username Section Blog Url IRC Nick Current Task SVN Username
Butnaru Stefan sbutnaru B Blog Fonzie - ops344_093svn115
Hughes Joseph jphughes B Cloudscorpion's Blog CloudScorpion - ops344_093svn112
Johnson Ausley aljohnson1 B My Blog Ausley_Johnson - ops344_093svn113
Kamal-Al-Deen Hasan hkamal-al-deen B The Orbital Station northWind87 - ops344_093svn111
Sandhu Charanjit cssandhu B Blog Charanjit - ops344_093svn114

Coding Standards

Coding standards are important if we want code to be readable. Now the jist of these rules is that they're "common sense" with readability in mind. The most important section is the commenting section as it is basically arbitrary while all the others should be more or less common sense. In any case, the entire thing is up here for reference purposes. We should all attempt to follow these guidelines when writing code.

While no one will be prosecuted or killed if they forget one or more of these, the others will gently remind the person in question to follow the guidelines :)

Naming Conventions

  • Camel Notation should be used for variable names and function names
    • ie myVar, bigInt, getNumber(), myFunction()
  • Class names should always be First-Letter Capitalized
    • ie TestClass, DynamicStack, PeanutButter, Hammer
  • Compiler directives should always be written in All Lowercase
    • ie #define, #ifndef
  • Compiler definitions should be All Uppercase and should only use underscore where a gap is required
    • ie IO_CTL_LARGEFILE, SOME_DEFINITION
  • Header file defines should be preceeded and followed with Two Underscores
    • ie __CIOL_H__, __IO_FORM_H__
  • Pointer declaration should emphasize the type with the "*" being pushed against the right side of the data type as opposed to the left side of the variable name.
    • ie char* str, int* num, void* addr
  • Binary operators should have a space between them and their constituents (Note: This does not apply to unary operators such as ++ or []).
    • ie x = 7, z += y, int i = 10, judge = y > 5
  • As well, please leave a space after every comma and every semicolon if something follows it.
    • ie foo(int firstInt, int secondInt, int thirdInt), x = bugSquish(parm1, parm2), for (int i = 0; i < 10; i++)
  • Finally, void should always be explicitly declared.
    • ie void doStuff(void), int getInt(void)

Statement Notation

The first left parenthesis on a function declaration should open immediately after the function name while the first left parenthesis on a loop declaration should open one space after the loop declaration.
ie Functions:

int hello(
char goodbye(
void getQuestion(

ie Loops:

while (
for (
do (

In the same sense, the first left parenthesis should immediately follow the function name when a function is called.
ie x = getInt(), someInt = y + bigSum(y, r)

Code Blocks

Both function blocks and loop blocks should open on the same line as the declaration statement preceding them; however, function blocks should open immediately after the last right parenthesis while loop blocks should open one space after the last right parenthesis.
ie Functions:

int hello(){
char goodbye(){
void getQuestion(void){

ie Loops:

while (var < 15) {
for (int i = 0; i < 15; i++) {
do (blah) {

Comment Blocks

All functions should have a comment block preceding them which should explain what the function does in a few brief sentences, what parameters it receives with each parameter having a section preceded by @param, and anything that the function may return preceded by @return at the end of the block. Try to keep things lined up so that they're easier to read.

Here is an example from Assignment 1 utilizing the io_strcpy() function:

/*Copies a given number of characters from one string to another.
 *Self copying is allowed. Does not stop at null-terminator, always copies 
 *the given number of characters. 
 *
 *@param const char* src  address from which to copy characters.
 *@param char* dest       address to which characters will be copied.
 *@param int n            number of characters to copy.
 *
 *@return the address of dest if copy was successful, NULL otherwise.
 */
char* io_strcpy(char* dest, const char* src, int n){

Commenting within the function should be generally organized, that's about it for in-function commenting.

As well, please ensure that a small commented header is at the top of every file (implementation if .cpp or header if .h). It should contain information such as the file name, project name, last modified date, last modified by, etc... Using the example of ciol.c from assignment 1, it should be in the following form:

/*  ##########################################################################
    Project:           OOP344 Assignment 1
    File Name:         ciol.c
    File Desc.:        Implementation file for console input output (CIOL) library.

    $LastChangedBy   ::                             $
    $LastChangedDate ::                             $
    $Rev             ::                             $
    ##########################################################################*/

Now SVN will actually automatically change the "last modified" lines as you commit files to the repository and this is done by using the following lines and the svn:keywords property:

    $LastChangedBy   ::                             $
    $LastChangedDate ::                             $
    $Rev             ::                             $

LastChangedBy will show the last person to have modified the file, LastChangedDate will show the date that this file was last modified on, and Rev will indicate the revision at which this file was last changed.

The svn:keywords property has already been globally set and propagated so it's in full use right now and all files that need a header should have one in the specified format.

That's about it folks, feel free to add or remove anything if you feel so compelled but please consult the rest of the group first if it is a major change.
-northWind87

Announcements

October 27, 2009 : Coding Standards added, meeting with Fardad at 5 pm Wednesday

OK! It was a long write but I've added all the necessary and agreed upon coding standards. As of now they are up here as a reference for everyone. Hopefully we can stick to the guidelines, gentlemen? As usual, if there are any disagreements or discrepancies on anything please feel free to consult me and/or the group in it's entirety.

I will be emailing you guys about this change very soon.

As well, we have an IRC meeting with Fardad at 5 pm tomorrow (Wednesday) in irc://irc.freenode.net/#seneca. Please be on IRC slightly in advance of 5 pm. -northWind87

October 25, 2009 : IRC meetings

As I've emailed you all, Fardad wants two IRC meetings with us during the study week so please indicate your availability (all of it, all times that you are available) during the study week here.

Aside from that, you may also notice the "meetings" section. This will be updated as we need to meet again. Hope to hear from you all soon. -northWind87

Study Week Availability

Hasan: Tuesday 11am - 2pm, Wednesday 11am - 6pm, Thursday 6:30pm - 10pm, Friday 6:30pm - 10pm, Saturday 11am - 9pm

Meetings

Tuesday October 27

Alright guys, first meeting ever. The tentative meeting time is so far somewhere in between the afternoon (ie 1 pm) and the evening (ie 5:30 pm) so your input would be highly appreciated.
Update: Seems like everyone is OK with Tuesday at 5:30 so that is when we will meet; please go to the TEL building first floor, we will meet there. Feel free to call me at 4169097925. We will also be deciding on when to speak with Fardad during the week, come ready to choose SOMETHING .
-northWind87

Agenda:

  • Design the general structure of the text editor and come to grips with what the assignment entails.
  • Discuss SVN use.
  • Declare all coding standards that we will need to follow so that our code doesn't look funny when it's put together :)
  • Assign sections and week by week requirements.
  • Decide on meeting times with Fardad.

Recommended Reading:

  • SVN manual (cuz it's just so pretty!)
  • Most of Assignment Two (I HIGHLY recommend doing this one)

That's all folks, please set this page and the OOP344_Assignment_Two page to be watched by wiki for you so that you're alerted of any changes. Please email me your input on the meeting time or anything else really.

As well, we're gonna have to speak to Fardad on IRC at some point although he hasn't been on IRC and hasn't emailed me about it yet so I'll let you all know once I know more. -northWind87