C++ Programming Ground Rules for CS226

Keep this nearby at all times! Points will be lost on programming assignments for not adhering to these standards!

General Rules

• All programming solutions must run successfully in MVC++ 6.0/NET for DOS.
• Programming assignments must be done individually. Generally, it's ok to discuss isolated details with others and to give and receive debugging help, but only in moderation. You must not borrow other people's work or compare more than a few lines of your work (either printed, as pseudocode, or on the screen) with others. Excessive collaboration will result in a 0 on the assignment for all students involved. Repeated instances may result in failing the course.
• All programs must adhere to the style and documentation standards given below. In most cases, these are similar to those given in the textbook, but there are some differences.

Organizing your Program

You must put the various sections of your C++ programs in the following order:

1. comment block, at the top of the file; the format for this block is given below
2. #include directives
3. global constants
4. type definitions, if any
5. function prototypes
6. main function
7. all other functions

There should be blank lines between each of these sections.

Documentation Standards

• Use the // comment style. Only use the /* */ comment style to temporarily comment out chunks of your program for testing and debugging.
• Every program must start with a comment block giving the class, date, your name, and what the program does. Follow the pattern

//---------------------------------------------------------------------
//
// Name:    your name
// 
// Course:  CS 226, Section 060A, Fall 2002
//
// Purpose: General description of what the program does.  This should
//          be at least several lines long and should discuss the
//          purpose of the program, the format of the input, and the
//          output the program produces.  This information should be
//          from a programmer's perspective (as opposed to the user's
//          perspective).
//
//---------------------------------------------------------------------

• Every function must have a comment which describes what it does and whether the parameters are input, output, or input and output. Include Precondition and Postcondition in your comments.  Be sure to document the purpose of any parameter which isn't obvious from its name alone. Thus a function header must have the following format:

//---------------------------------------------------------------------
// A few lines describing what the function does.
// params: (in/out/inout, ...)
//---------------------------------------------------------------------
result_type function_name(type1 param1, type2 param2, ...)

//---------------------------------------------------------------------
// This function uses hours and rate to compute and return the gross
// pay and the net pay of an employee.
// params: (in, in, out, out)
//---------------------------------------------------------------------
void ComputePay(int hours, float rate, float& GrossPay, float& NetPay)

• Comment sections of code within functions, but don't over-do it. Excessive comments can be distracting, and comments that add nothing to the understanding of the code are particularly distracting. For example,

        count = count + 1;      // add one to count

Names

• Use descriptive names! You'll find that this not only improves your grade, but it also makes your programs easier to write and debug. If you're tempted to use a poor name for something, then you probably don't completely understand the problem you're trying to solve yet! Figure that out first before trying to go on.
• Variable names should generally be nouns or noun phrases such as grade and grade_for_student. The exception is for loop counters; this is the only place where it is sometimes acceptable to use a one-letter name (such as i or j).
• Names for functions with a return type of void should generally be verb phrases such as ComputePay() and PrintOrders().
• Names for functions with other return types should generally be nouns or noun phrases such as Average() and MonthlySalary().
• Every numeric constant in your program (such as 3.14 or 25) must be given a name. That is, there should be a declaration such as

        const int CLASS_SIZE = 25;      // students in class

        const int TEN = 10;             // useless!

• All constant declarations must be global. That is, they must be declared at the beginning of your program.

Formatting

• Indent your programs! You must indent 3 spaces
  • inside all brace pairs, and
  • for simple statements following if, while, for, switch, and do.

• Statements that are spread over multiple lines must be indented to make it obvious which lines are continuations. For example,

        cout << "The cost for 1 loaf of bread" << endl
             << "is $1.89" << endl;

• When a line gets too long (more than 80 columns), break it at a reasonable place. You will lose points for handing in program listings that are confusing to read because the ends of lines are either missing or show up at the beginning of the next line. Before you submit a printout, check it to make sure it is easy to read. If it isn't, reformat your solution, re-run the grader, and reprint the result!
• Each brace ({ and }) must appear on its own line. Line up the braces to make it clear how they are matched. For example,

        if ( radius > 0 )
        {
           area = PI * radius * radius;
        }

• Each line must contain at most one statement, though a single statement may be spread over multiple lines.
• There must be a space before and after each operator (including +, *, /, %, =, <<, >>, <, <=, >, >=, ==, ||, and &&). Use one space after a comma.

Output

• For all programs submitted , you must follow the specified output format EXACTLY. All data must appear in the exact columns as specified by the program description and with the exact format. Pay particular attention to the number of spaces in lines and how they have been used to line up columns. All lines must be in there, including blank lines. Moreover, there can be no extra lines. Making output appear exactly as required is a skill all good programmers should master! 
• Be sure to look at your output! Does it make sense to you? Just because your program produces output doesn't mean it works!

Submit based on these handouts . Your project should include the following parts (source code is  mandatory and program should be executable):           

1. Problem Solving (state the problem description) (2 point)
2. Algorithm (10 points)
3. Test Plan (5 points)
4. Source code (email me .cpp and .h files)
5. Source code must include comments (see the guidelines below)(20points)
6. Output (screen shots) (20  point)