The complete CSCI 1300/2270 Programming Style Guide is shown below. The most important issues (which we'll always grade on!) are:
In order to allow easy reading and understanding of everybody's programs, and to avoid risky programming practices, all software organizations have guidelines that programmers must follow. This page contains the guidelines we require you to follow in CSCI1300. For your interest, you might also look at some a real-world programming stylesheets.
At the same time, this page defines abbreviations that we can use in providing feedback to you on your programs. For example, if we mark II on a program you turn in, this sheet tells you that we think you have used incorrect indenting.
So, here's a list of bad things we'll be looking for in your programs, and the abbreviations we'll use to notify you if we find them.
RULE 1: Incremental Development and Testing
RULE 2: Fixing Bugs
If you come to me and say, "My program was crashing, so I thought I would try such-and-such," then I will send you away.
If I point out a wrong piece of code and you say, "I had it right, but the program wasn't working, so I changed it," then I will send you away.
Never change correct code to something that you know is wrong or to something that you are trying because it seemed to work for someone else. You must identify the problem and know how to fix it before you change your code. If you want to try something to see how it works, then do so in a separate small program that focuses on just that feature. I mean it: I'll send you away.
Having said all this, I'll also add that it is fine to play around with a program in order to get more information about what is going wrong or to better understand the language features. But before you start playing, make sure that you have saved your original program in a separate location.
FTL Function too long.
LTL Lines too long.
FCI File comment incomplete.
II Incorrect indenting.
There are many ways people indent their C++ code, but the one way that we'll accept is described here. This way has some advantages in readability, but more than that (1) if you are all consistent it helps us read your code, and (2) in real life you'll have to get used to following specific guidelines in your code, so why not get some practice now.
The rules are:
void foo(int x, int y)
for (i = 0; i < N; i++)
cout << i << endl;
cout << i*i << endl;
if (i > M)
cout << "M exceeded" << endl;
WS White space.
if, and one space after each semi-colon in the control of a for-loop.
BN Bad name.
CN Capitalization and naming style.
plant_age. Names of constants are all upper-case letters with underscores to separate new words, such as
that do not return a value (void function) must have
a verb as the first part of the name (such as
Functions that return a bool value must have the word "is" as the first
part of the name (such as
Other functions that return a value must have a descriptive noun or
as the entire name (such as
GV Global variable.
DC Define constants.
PCI Prototype Comment Incomplete.
ECI Explanatory Comments Incomplete.
UC Unnecessary comment.
CTC Code too complex.
FRP Function return problem.
returnto send information back to the calling program. Use non-const reference parameters only when you must. (generally, when the function produces several pieces of information). Avoid functions that return information with a
returnstatement and also returns other information through its parameters. Avoid using an if-else statement to return a boolean value. For example, consider this code:
if (x < 0)The preference is to omit the if-statement and just have a return statement:
return (x < 0);.
BUI Bad user interface.
DNW Does not work.
PDR Poor data representation.
MD Misplaced declaration or definition.
As shown in the textbook, function prototypes should precede main() and function definitions should follow main(). These must be in alphabetical order to make them easy to find.
NMR Needs to be more robust.
NGE Not general enough.
CF Combine functions.