There are a list of style specifications. You should follow them to get full credit. You may lose some points for not following them.

• Add a single space after commas

  Instead of writing:

     foo(arg1,arg2,arg3);
  

  which has no spaces after commas, you should write

     foo(arg1, arg2, arg3);
  

  or you should write:

     foo( arg1, arg2, arg3 );
  

  This makes your code easier to read.

• Add at least single space before and after operators

  In particular, put at least single space between =, ==, !=, <, <=, >, >=, ||, &&, <<, >>.

  For example, instead of writing:

     if(a>=b||c!=d+2) {
        x=foo(z,y);
        cout<<x<<endl;
     }
  

  you should write:

     if(a >= b || c != d+2) {
        x = foo(z, y);
        cout << x << endl;
     }
  

  or

     if( a >= b || c != d + 2 ) {
        x = foo( z, y );
        cout << x << endl;
     }
  

• Write sufficient comments

  A comment every 5 to 10 lines should suffice. Try to write the comments BEFORE writing much code. It will help you in the long run. Really.

• Use some reasonable bracing method

  Here are some choices:

  • K&R. Open brace is at the end of while, if, for. Matching brace is underneath the first letter of while, if, or for.

    if ( x == y ) {  // Open brace up here
       x++;
       y--;
    }  // Close brace lines up with 'i' in if.
    else
       cout << x << endl;   
    

  • GNU. Open brace is indented underneath, and code is indented even further. Close brace is at the same indentation level as the open brace.

    if ( x == y ) 
      {  // Open brace indented in
         x++;  // Indented some more
         y--;  // Lines up
      } // Matches open brace
    else
       cout << x << endl;   
    

  • Allman. Open brace is underneath the first letter of while, if, or for. Code is indented from braces. Close brace is at the same indentation level as the open brace.

    if ( x == y ) 
    { // Open brace lines up with 'i' in "if"
       x++;   // Indented in
       y--;   // Lines up with previous line
    } // Close brace lines up with 'i' in "if"
    else
       cout << x << endl;   
    

• Use either Underscore or Uppercase for variable names
  • Uppercase. One word variable names are lowercase. E.g., "count", "height", "cost". Multiword variable names capitalize every word except first. "numDonuts", "leftMaxHeight", "costOfOranges".
  • Underscore. One word variable names are lowercase. E.g., "count", "height", "cost". Multiword variable names use underscores to separate. No uppercase used. E.g. "num_donuts", "left_max_height", "cost_of_oranges".

• Capitalize the first letter of class names

  E.g., ArraySortedList, or Array_sorted_list.

  This makes it easier to determine what's a class and what's not. STL uses lowercase for its classes, however.

• Write constants in uppercase and underscores

  E.g., PI, LOCAL_TAX, ARRAY_LIST_H

  This makes it easier to determine what's a class and what's not. STL uses lowercase for its classes, however.

• Try writing preconditions and postconditions

  This is a suggestion, not a requirement. A precondition is a logical statement which defines what must be true before the code can be successfully run. In particular, it generally states assumptions about the range of valid values for the parameters.

  A postcondition for a method is a logical statement that defines what will be the result of running the code. Typically, it describes what return values to expect, and what modifications will be made to the object.

• Try writing class invariants

  Also a suggestion, not a requirement.

  Class invariants are properties you wish the class to maintain at all times. A constructor should establish the invariants. Each method can assume that the class invariant is true prior to running, and each method should guarantee the class invariant is true after executing the method. Thus, class invariants are considered preconditions and postconditions to all methods (they are only postconditions to constructors and preconditions to destructors).

  An example of a class invariant is that a doubly linked list is either empty (NULL) or it has one or more elements. Another invariant is that the list is sorted based on a certain key. Another invariant is that the number of elements in the list should match the "listSize" data member.

  Such invariants help you to debug the code. For example, suppose you have a class that contains a vector. You can state that one invariant that the vector is always sorted. Thus, if you enter a method, you can assume that the vector is sorted.

• When commenting a method, write which data members are modified.

  Again, a suggestion not requirement.

  This is useful when determining whether a method should be const or not. Always favor making the method const, if possible.

• When commenting a method, determine running time efficiency using Big O notation

  Again, a suggestion not requirement.

  Helps you to think about how efficient the method you're writing, and whether it coudl be improved.

Ideally, you want some math formalism like formal logic to help you describe the class. However, this can be difficult to get correct. Nevertheless, describing in math formalism is often more precise than describing in English (although, you can write a "English translation" to help those who may find the math formalism difficult to read).

Web Accessibility