p4-battleship

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;
      }
      // bad
      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

Comments

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

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

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