Difference between revisions of "OOP344 - FjXR - 20102"
Line 18: | Line 18: | ||
|} | |} | ||
+ | == Coding Style == | ||
− | == Common Hungarian Notation Prefixes == | + | === Common Hungarian Notation Prefixes === |
<p> | <p> | ||
Line 63: | Line 64: | ||
− | |||
− | |||
=== File names === | === File names === | ||
Line 72: | Line 71: | ||
the option of having no file name extension is used,<br/> | the option of having no file name extension is used,<br/> | ||
i.e.: #include <iostream>. | 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/> | ||
+ | int func(int a); | ||
+ | <br/> | ||
+ | <br/> | ||
+ | <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> | ||
+ | <br/> | ||
+ | int func(int a) { | ||
+ | <br/> | ||
+ | <br/> | ||
+ | <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> | ||
+ | <br/> | ||
+ | int func(int a) { | ||
+ | int b = a + 1; | ||
+ | return b * 2; | ||
+ | } | ||
+ | <br/> | ||
+ | <br/> | ||
+ | <p>and for a single-line definition that is often used for inlines:</p> | ||
+ | <br/> | ||
+ | int func(int a) { return (a + 1) * 2; } | ||
+ | <br/> | ||
+ | <br/> | ||
+ | <p> | ||
+ | Placing the ‘{‘ on the next line eliminates some confusing code | ||
+ | in complex conditionals, aiding in the scannability. Example: | ||
+ | </p> | ||
+ | <br/> | ||
+ | if(cond1<br/> | ||
+ | && cond2<br/> | ||
+ | && cond3) {<br/> | ||
+ | statement;<br/> | ||
+ | }<br/> | ||
+ | <br/> | ||
+ | <p> | ||
+ | The above has poor scannability. However, | ||
+ | </p> | ||
+ | <br/> | ||
+ | if (cond1<br/> | ||
+ | && cond2<br/> | ||
+ | && cond3)<br/> | ||
+ | {<br/> | ||
+ | statement;<br/> | ||
+ | }<br/> | ||
+ | <br/> | ||
=== Parentheses, braces, and indentation === | === Parentheses, braces, and indentation === |
Revision as of 14:20, 31 May 2010
Contents
We are FjXR, Code fixers are ready to go!
Group member
Group | 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 |
Coding Style
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."
(See Example Below)
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:
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:
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:
int func(int a) {
int b = a + 1;
return b * 2;
}
and for a single-line definition that is often used for inlines:
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:
if(cond1
&& cond2
&& cond3) {
statement;
}
The above has poor scannability. However,
if (cond1
&& cond2
&& cond3)
{
statement;
}