Difference between revisions of "OOP344 - FjXR - 20102"
(→Group member) |
|||
(42 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
=''We are FjXR, Code fixers are ready to go!''= | =''We are FjXR, Code fixers are ready to go!''= | ||
− | == Group member== | + | == Group member == |
− | {| class="wikitable sortable" border="1" cellpadding="5" align=" | + | {| class="wikitable sortable" border="1" cellpadding="5" align="auto" |
− | |+ | + | |+ '''TERM 20102''' |
− | ! First Name !! Last Name !! Section !! Seneca Id !! wiki id !! IRC nick !! Blog URL | + | ! ID !! First Name !! Last Name !! Section !! Seneca Id !! wiki id !! IRC nick !! Blog URL |
|- | |- | ||
− | | [[User:Xlu44 | Xiongwen Lu ]] || xlu44 || A || [mailto:xlu44@learn.senecac.on.ca xlu44] || [[Special:Contributions/xlu44 | xlu44]] || xlu44 || [http://myoop344blog.blogspot.com/ my blog] | + | | A || [[User:Xlu44 | Xiongwen Lu ]] || xlu44 || A || [mailto:xlu44@learn.senecac.on.ca xlu44] || [[Special:Contributions/xlu44 | xlu44]] || xlu44 || [http://myoop344blog.blogspot.com/ my blog] |
|- | |- | ||
− | | [[User:jpark68 | Junseok]] || Park|| A ||[mailto:jpark68@learn.senecac.on.ca Junseok] || [[Special:Contributions/jpark68 | jpark68]] || jpark68|| [http://jpark68.blogspot.com/ My Blog] | + | | B || [[User:jpark68 | Junseok]] || Park|| A ||[mailto:jpark68@learn.senecac.on.ca Junseok] || [[Special:Contributions/jpark68 | jpark68]] || jpark68|| [http://jpark68.blogspot.com/ My Blog] |
|- | |- | ||
− | | [[User:Rhui4 | Richard]] || Hui || A ||[mailto:rhui4@learn.senecac.on.ca rhui4] || [[Special:Contributions/Rhui4 | Rhui4]] || Rhui4|| [http://rhui4.wordpress.com/ My Blog] | + | | C || [[User:Rhui4 | Richard]] || Hui || A ||[mailto:rhui4@learn.senecac.on.ca rhui4] || [[Special:Contributions/Rhui4 | Rhui4]] || Rhui4|| [http://rhui4.wordpress.com/ My Blog] |
+ | |- | ||
+ | | D || [[User:Priya | Priya]] || Gill || A ||[mailto:pkgill5@learn.senecac.on.ca pkgill5] || [[Special:Contributions/priya | priya]] || pkgill5|| [http://rhui4.wordpress.com/ My Blog] | ||
+ | |- | ||
+ | | E || [[User:lwang168 | Liang Wang ]] || lwang168 || A || [mailto:lwang168@learn.senecac.on.ca lwang168] || [[Special:Contributions/lwang168 | lwang168]] || lwang168 || [http://lwang168.blogspot.com/ my blog] | ||
+ | |- | ||
+ | |} | ||
+ | == Notification Window == | ||
+ | <!--<object width="250" height="360" id="obj_1275427285642"><param name="movie" value="http://fjxr.chatango.com/group"/><param name="wmode" value="transparent"/><param name="AllowScriptAccess" VALUE="always"/><param name="AllowNetworking" VALUE="all"/><param name="AllowFullScreen" VALUE="true"/><param name="flashvars" value="cid=1275427285642&b=60&f=50&l=999999&q=999999&r=100&s=1"/--><embed id="emb_1275427285642" src="http://fjxr.chatango.com/group" width="250" height="360" wmode="transparent" allowScriptAccess="always" allowNetworking="all" type="application/x-shockwave-flash" allowFullScreen="true" flashvars="cid=1275427285642&b=60&f=50&l=999999&q=999999&r=100&s=1"></embed><!--/object><br>[ <a href="http://fjxr.chatango.com/clonegroup?ts=1275427285642">Copy this</a> | <a href="http://chatango.com/creategroup?ts=1275427285642">Start New</a> | <a href="http://fjxr.chatango.com">Full Size</a> ]--> | ||
+ | == Coding Style == | ||
+ | |||
+ | * References from the books of "Thinking in C++ (2nd Edition) by Bruce Eckel" and " Programming Windows with MFC (2nd edition) by Jeff Prosise, Microsoft Press " | ||
+ | * download the book here.<br/> | ||
+ | Thinking in C++,Volume 1, 2nd Edition by Bruce Eckel<br/> | ||
+ | http://matrix.senecac.on.ca/~jpark68/TIC2Vone.pdf <br/> | ||
+ | Volume 2: Standard Libraries & Advanced Topics<br/> | ||
+ | http://matrix.senecac.on.ca/~jpark68/TIC2Vtwo.pdf <br/> | ||
+ | |||
+ | |||
+ | == Common Hungarian Notation Prefixes == | ||
+ | |||
+ | <p> | ||
+ | Prefixes are often combined to form other prefixes, as when '''p''' and '''sz''' are joined to form '''psz''', which stands for "pointer to zero-terminated string." </p> | ||
+ | |||
+ | example: | ||
+ | |||
+ | int nCount = 45 ; | ||
+ | char szUserName[20]; | ||
+ | char* pszUserName[20]; | ||
+ | char cLetter = 'a' ; | ||
+ | |||
+ | |||
+ | {| class="wikitable sortable" border="1" cellpadding="5" align="auto" | ||
+ | |||
+ | ! Prefix !! Data Type | ||
+ | |- | ||
+ | | b || BOOL | ||
+ | |- | ||
+ | | c or ch || char | ||
+ | |- | ||
+ | | clr || COLORREF | ||
+ | |- | ||
+ | | cx, cy || Horizontal or vertical distance | ||
+ | |- | ||
+ | | dw || DWORD | ||
+ | |- | ||
+ | | h || Handle | ||
+ | |- | ||
+ | | l || LONG | ||
+ | |- | ||
+ | | n || int | ||
+ | |- | ||
+ | | p || Pointer | ||
+ | |- | ||
+ | | sz || Zero-terminated string | ||
+ | |- | ||
+ | | w || WORD | ||
+ | |- | ||
+ | | f || float | ||
|- | |- | ||
|} | |} | ||
+ | |||
+ | === File names === | ||
+ | |||
+ | to use '''.cpp''' for implementation files and '''.h''' for header files.<br/> | ||
+ | Note that when including Standard C++ header files,<br/> | ||
+ | the option of having no file name extension is used,<br/> | ||
+ | i.e.: #include <iostream>. | ||
+ | |||
+ | === Parentheses, braces, and indentation === | ||
+ | <p> | ||
+ | the opening brace should always go on the same line as the “precursor” (by which I mean | ||
+ | “whatever the body is about: a class, function, object definition, if | ||
+ | statement, etc.”). This is a single, consistent rule I apply to all of the | ||
+ | code I write, and it makes formatting much simpler. It makes the | ||
+ | “scannability” easier – when you look at this line:</p><br/> | ||
+ | |||
+ | example: | ||
+ | |||
+ | int func(int a); | ||
+ | |||
+ | <p> | ||
+ | you know, by the semicolon at the end of the line, that this is a | ||
+ | declaration and it goes no further, but when you see the line:</p> | ||
+ | |||
+ | example: | ||
+ | int func(int a) { | ||
+ | |||
+ | <p> | ||
+ | you immediately know it’s a definition because the line finishes | ||
+ | with an opening brace, not a semicolon. By using this approach, | ||
+ | there’s no difference in where you place the opening parenthesis | ||
+ | for a multi-line definition:</p> | ||
+ | |||
+ | example: | ||
+ | |||
+ | int func(int a) { | ||
+ | int b = a + 1; | ||
+ | return b * 2; | ||
+ | } | ||
+ | |||
+ | <p>and for a single-line definition that is often used for inlines:</p> | ||
+ | |||
+ | example: | ||
+ | |||
+ | int func(int a) { return (a + 1) * 2; } | ||
+ | |||
+ | <p> | ||
+ | Placing the ‘{‘ on the next line eliminates some confusing code | ||
+ | in complex conditionals, aiding in the scannability. Example: | ||
+ | </p> | ||
+ | |||
+ | example: | ||
+ | |||
+ | if(cond1 | ||
+ | && cond2 | ||
+ | && cond3) { | ||
+ | statement; | ||
+ | } | ||
+ | |||
+ | <p> | ||
+ | The above has poor scannability. However, | ||
+ | </p> | ||
+ | |||
+ | example: | ||
+ | |||
+ | if (cond1 | ||
+ | && cond2 | ||
+ | && cond3) | ||
+ | { | ||
+ | statement; | ||
+ | } | ||
+ | |||
+ | <p>breaks up the ‘if’ from the body, resulting in better readability. | ||
+ | Finally, it’s much easier to visually align braces when they are | ||
+ | aligned in the same column. They visually "stick out" much | ||
+ | better.</p><br/> | ||
+ | |||
+ | |||
+ | === Identifier names === | ||
+ | |||
+ | <p>The style is quite straightforward. The first letter of an identifier is | ||
+ | only capitalized if that identifier is a class. If it is a function or | ||
+ | variable, then the first letter is lowercase. The rest of the identifier | ||
+ | consists of one or more words, run together but distinguished by | ||
+ | capitalizing each word. So a class looks like this:</p><br/><br/> | ||
+ | |||
+ | example: | ||
+ | class FrenchVanilla : public IceCream { | ||
+ | |||
+ | an object identifier looks like this: | ||
+ | |||
+ | example: | ||
+ | FrenchVanilla myIceCreamCone(3); | ||
+ | |||
+ | and a function looks like this: | ||
+ | |||
+ | example: | ||
+ | void eatIceCreamCone(); | ||
+ | |||
+ | (for either a member function or a regular function). | ||
+ | |||
+ | === Include guards on header files === | ||
+ | |||
+ | <p>Include guards are always used inside header files to prevent | ||
+ | multiple inclusion of a header file during the compilation of a | ||
+ | single .cpp file. The include guards are implemented using a | ||
+ | preprocessor #define and checking to see that a name hasn’t | ||
+ | already been defined. The name used for the guard is based on the | ||
+ | name of the header file, with all letters of the file name uppercase | ||
+ | and replacing the ‘.’ with an underscore. For example:</p><br/> | ||
+ | |||
+ | example: | ||
+ | |||
+ | // IncludeGuard.h | ||
+ | #ifndef INCLUDEGUARD_H | ||
+ | #define INCLUDEGUARD_H | ||
+ | // Body of header file here... | ||
+ | #endif // INCLUDEGUARD_H | ||
+ | |||
+ | === Use of namespaces === | ||
+ | |||
+ | if you change the namespace outside of a function or class, you will cause | ||
+ | that change to occur for any file that includes your header, | ||
+ | resulting in all kinds of problems. | ||
+ | In cpp files, any global using directives will only affect that file, | ||
+ | and so you are generally used to produce more easilyreadable | ||
+ | code, especially in small programs. | ||
+ | |||
+ | example: | ||
+ | |||
+ | #include <cstdlib> // malloc() & free() | ||
+ | #include <cstring> // memset() | ||
+ | #include <iostream> | ||
+ | using namespace std; |
Latest revision as of 15:08, 3 June 2010
Contents
We are FjXR, Code fixers are ready to go!
Group member
ID | First Name | Last Name | Section | Seneca Id | wiki id | IRC nick | Blog URL |
---|---|---|---|---|---|---|---|
A | Xiongwen Lu | xlu44 | A | xlu44 | xlu44 | xlu44 | my blog |
B | Junseok | Park | A | Junseok | jpark68 | jpark68 | My Blog |
C | Richard | Hui | A | rhui4 | Rhui4 | Rhui4 | My Blog |
D | Priya | Gill | A | pkgill5 | priya | pkgill5 | My Blog |
E | Liang Wang | lwang168 | A | lwang168 | lwang168 | lwang168 | my blog |
Notification Window
<embed id="emb_1275427285642" src="http://fjxr.chatango.com/group" width="250" height="360" wmode="transparent" allowScriptAccess="always" allowNetworking="all" type="application/x-shockwave-flash" allowFullScreen="true" flashvars="cid=1275427285642&b=60&f=50&l=999999&q=999999&r=100&s=1"></embed>
Coding Style
- References from the books of "Thinking in C++ (2nd Edition) by Bruce Eckel" and " Programming Windows with MFC (2nd edition) by Jeff Prosise, Microsoft Press "
- download the book here.
Thinking in C++,Volume 1, 2nd Edition by Bruce Eckel
http://matrix.senecac.on.ca/~jpark68/TIC2Vone.pdf
Volume 2: Standard Libraries & Advanced Topics
http://matrix.senecac.on.ca/~jpark68/TIC2Vtwo.pdf
Common Hungarian Notation Prefixes
Prefixes are often combined to form other prefixes, as when p and sz are joined to form psz, which stands for "pointer to zero-terminated string."
example:
int nCount = 45 ; char szUserName[20]; char* pszUserName[20]; char cLetter = 'a' ;
Prefix | Data Type |
---|---|
b | BOOL |
c or ch | char |
clr | COLORREF |
cx, cy | Horizontal or vertical distance |
dw | DWORD |
h | Handle |
l | LONG |
n | int |
p | Pointer |
sz | Zero-terminated string |
w | WORD |
f | float |
File names
to use .cpp for implementation files and .h for header files.
Note that when including Standard C++ header files,
the option of having no file name extension is used,
i.e.: #include <iostream>.
Parentheses, braces, and indentation
the opening brace should always go on the same line as the “precursor” (by which I mean “whatever the body is about: a class, function, object definition, if statement, etc.”). This is a single, consistent rule I apply to all of the code I write, and it makes formatting much simpler. It makes the “scannability” easier – when you look at this line:
example:
int func(int a);
you know, by the semicolon at the end of the line, that this is a declaration and it goes no further, but when you see the line:
example:
int func(int a) {
you immediately know it’s a definition because the line finishes with an opening brace, not a semicolon. By using this approach, there’s no difference in where you place the opening parenthesis for a multi-line definition:
example:
int func(int a) { int b = a + 1; return b * 2; }
and for a single-line definition that is often used for inlines:
example:
int func(int a) { return (a + 1) * 2; }
Placing the ‘{‘ on the next line eliminates some confusing code in complex conditionals, aiding in the scannability. Example:
example:
if(cond1 && cond2 && cond3) { statement; }
The above has poor scannability. However,
example:
if (cond1 && cond2 && cond3) { statement; }
breaks up the ‘if’ from the body, resulting in better readability. Finally, it’s much easier to visually align braces when they are aligned in the same column. They visually "stick out" much better.
Identifier names
The style is quite straightforward. The first letter of an identifier is only capitalized if that identifier is a class. If it is a function or variable, then the first letter is lowercase. The rest of the identifier consists of one or more words, run together but distinguished by capitalizing each word. So a class looks like this:
example:
class FrenchVanilla : public IceCream {
an object identifier looks like this:
example:
FrenchVanilla myIceCreamCone(3);
and a function looks like this:
example:
void eatIceCreamCone();
(for either a member function or a regular function).
Include guards on header files
Include guards are always used inside header files to prevent multiple inclusion of a header file during the compilation of a single .cpp file. The include guards are implemented using a preprocessor #define and checking to see that a name hasn’t already been defined. The name used for the guard is based on the name of the header file, with all letters of the file name uppercase and replacing the ‘.’ with an underscore. For example:
example:
// IncludeGuard.h #ifndef INCLUDEGUARD_H #define INCLUDEGUARD_H // Body of header file here... #endif // INCLUDEGUARD_H
Use of namespaces
if you change the namespace outside of a function or class, you will cause that change to occur for any file that includes your header, resulting in all kinds of problems. In cpp files, any global using directives will only affect that file, and so you are generally used to produce more easilyreadable code, especially in small programs.
example:
#include <cstdlib> // malloc() & free() #include <cstring> // memset() #include <iostream> using namespace std;