# Style Deductions

## Top Comment

Must have name, uniqname, program name, and project description at the top of the file.

If all or part of the top comment is missing, take 1 point off.

## Readability violations: -1 for each of the following categories

Category Possible Violations

Indentations

• Not using a consistent number of spaces for each level of code indentation

• This includes using tabs on some lines and spaces on others

• Not indenting lines at all

• Failing to indent the blocks of code inside curly braces

Spacing

• Not putting a space around operators (e.g., 5*7 instead of 5 * 7 or count=0; instead of count = 0;)

• Includes stream insertion and extraction operators

• Not putting a space between if, while, or for and the condition to be evaluated

• Putting a space between a function name and the opening parenthesis

Bracing

• Using a mix of Egyptian-style and hanging braces

• Egyptian-style: '{' at the end of a statement

• Hanging: '{' on its own line

• Braces should always be used for conditionals, loops, and functions.

• Examples:

// good
if (x == 1) {
return false;
}
if (x == 2)
{
return true;
}
if (x == 1) return false;
if (x == 2)
return true;

Variables

• Variable names not meaningful

• Inconsistent variable naming style (camelCase vs. snake_case)

• Excluding const variables, which are always SNAKE_CASE

• Not declaring constant variables as const

• Not using all uppercase SNAKE_CASE for const variable names

• Using variable types that do not make sense in context

Line limit

• Going over 80 characters on a line

• Includes lines of comments and lines of code

Statements

• More than one statement on a single line.

• A statement ends in a semicolon.

• Do not count off for multiple statements as part of a for loop declaration

• Commenting on the end of a line of code

// A comment should be placed before a line of code
int count = 0; // not on the same line as the code

• Code should be thoroughly commented such that lines’ functionality is apparent from comments alone or from quickly glancing at code

• Example of appropriate comment:

// convert cups of flour to bags of flour
int bagFlour = ceil((CUPS_FLOUR * numBatches) /
CUPS_IN_LB_FLOUR);

// declare variable
int bagFlour;
// calculate cags of flour
bagFlour = ceil((CUPS_FLOUR * numBatches) /
CUPS_IN_LB_FLOUR);
• Unneeded comments left in the code, such as:

// your code goes here
// this function doesn't work
// NEEDS TO BE FIXED
// FIXED
• Commented out code, such as:

// int numBatches = people / 12;
int numBatches = ceil(people / NUM_IN_BATCH);

RMEs

• Missing RMEs for any of the defined functions (exception: main). This includes functions from the distribution code and any functions created by the student.

• Having RMEs outside of header files

## Coding quality: -2 for each of the following categories

Category Possible Violations

Global variables

• Global variables not declared as const

Magic numbers

• Using 8 instead of MAX_GRID_SIZE

0, 1, 2, 3, 4, and 5 are okay

Egregious code

• Logic that is clearly too involved or incorrect

• e.g. instead of using loops, writing:

grid[0][0] = '-';
grid[0][1] = '-';
grid[0][2] = '-';
grid[0][3] = '-';
grid[0][4] = '-';
grid[0][5] = '-';
grid[0][6] = '-';
grid[0][7] = '-';
grid[1][0] = '-';

and so on

Function Misuse

• Not calling helper functions where appropriate. Examples include, but are not limited to, the following

• Reimplementing Player::init_grid instead of calling it where appropriate

• Having tester functions remaining in your submission for the regular project (of course, does not apply to test.cpp)

bools

• Only deduct 1 point for this category

• Writing <bool> == true, <bool> != true, <bool> == false, <bool> != false

• Same for comparing bools to 0 and 1

• Returning 0 and 1 instead of true and false for a bool function