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


  • 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


  • 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


  • 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;
      // bad
      if (x == 1) return false;
      if (x == 2)
          return true;


  • 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


  • 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
  • Insufficient comments or excessive comments

    • 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) /
    • Example of excessive comments:

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

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

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


  • 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 reads and writes, instead of calling read and write method functions or using overloaded insertion and extraction operators

    • 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)


  • 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