Programming Guidelines#

The current syllabus, assignment instructions, and applicable CSN or college policies are the official sources for grading policy. Those sources take precedence over this page.

This page explains standards that stay mostly the same from semester to semester. If you are new, transferring, or returning after time away, do not read this page as a list of things you must already know before the course begins. Use it as a stable reference for the habits you will practice in CS 135 and CS 202.

Academic integrity#

For each program, work individually unless the assignment says otherwise. You may discuss the problem with classmates, but you may not discuss code in any form.

Do not show another student your code. Do not share your file with another student. Do not look at another student’s code. Do not tell another student what to type.

Evidence of academic dishonesty will result in a score of zero, as described in the Academic Integrity section of the syllabus. This applies to all students involved. If you are unsure whether something is allowed, ask before doing it.

Follow the assignment#

Your program must meet the problem statement requirements and the coding standards below. Violations may lead to deductions.

The assignment instructions control the details for a specific program. Read them before you write code and again before you submit.

Required header comment#

Each submitted source file must begin with a header comment. A submission without the required header comment will receive a grade of zero.

Use this pattern unless the assignment gives a different one:

/**
 *  @file FILE_NAME
 *  @author YOUR_NAME
 *  @date THE_DATE
 *  @note I pledge my word of honor that I have complied with the
 *  CSN Academic Integrity Policy while completing this assignment.
 *  @brief A brief description of the program, no more than one or two
 *  paragraphs.
 *  @note Time taken to develop, write, test, and debug the solution.
 *  @note ChatGPT Study and Learn session: LINK_OR_DESCRIPTION
 */

Failure to disclose assistance, regardless of source, may be interpreted as academic dishonesty. Follow the disclosure requirements in the assignment and syllabus.

Blocks and indentation#

Use braces for blocks, following the methods demonstrated in class. Brace placement is your choice, but it must be consistent throughout the program.

Indent statements according to their logical nesting. Use four spaces per indent level. Do not use tabs.

Variables and constants#

Declare one variable per declaration. Place the declaration at the beginning of the smallest block where the variable is used.

Do not use the comma operator to declare several variables in one statement. Do not mix declarations with executable statements.

Use descriptive variable names that follow the naming standards discussed in class. Reduce the scope of each variable so it is visible only where it is needed.

Global variables are never permitted. Global constants are permitted when they are appropriate.

Document the purpose of every identifier you create, including constants, variables, and functions.

Statements#

Write no more than one statement on a line.

Do not use continue or goto. Do not use break except in a switch statement.

Reserve exit for unrecoverable errors, such as failed memory allocation. Handle errors gracefully wherever possible.

Keep lines of code to 80 characters or fewer.

Remove diagnostic or debugging print statements before submission. Submit a shipping version of your program. In advanced courses, conditional compilation may be used to enable or disable debugging statements.

Functions#

Use descriptive function names that follow the naming standards discussed in class.

Document every function. Function documentation must describe:

the purpose of the function
the purpose of each parameter
the return value, for value-returning functions

When a program uses a single source file, place function documentation directly above the function definition, not above the prototype.

When a larger project uses multiple source files, place function documentation directly above the function prototypes in the interface file, not in the implementation file.

Example function documentation header:

/**
 *  @brief The function foo.
 *
 *  Description of what the function does. This part may refer to the
 *  parameters of the function, like @p param1 or @p param2.
 *
 *  @param param1 Description of the first parameter of the function.
 *  @param param2 The second parameter, which follows @p param1.
 *  @return Describe what the function returns.
 *
 *  @see Optional reference, if required.
 *  @note Something to note.
 *  @warning Warning.
 */
int foo(int param1, int param2);

Do not write long function bodies when the work can be divided into smaller functions. A function should do one thing and do it clearly.

Non-recursive functions should contain exactly one return statement. A function should have one entry point and one exit point.

Compile and test on Bellagio#

Your program must compile cleanly, with no warnings, and run properly on the Bellagio server for credit.

Late programs and programs with syntax errors, which means programs that do not compile, will receive a grade of zero unless the current syllabus or assignment instructions say otherwise.

It is better to submit a partially correct program that compiles than no program at all.

C++ language standard#

All programs must conform to the C++14 language standard.

Use only C++14 features and libraries that have already been introduced in the assigned textbook, lectures, or prior sample solutions. Do not use deprecated features from older standards. Do not use features from newer versions of C++.

Submission#

Submit the required program file or files using the procedure shown in the assignment instructions.

You may submit as many times as you want before the deadline. Each submission replaces the earlier one, so only the most recent submission can be graded.

Submit all required files with each submission. You cannot submit after the deadline once the drop box is closed.