Course Coding Standards | Coursera

This reading describes the coding standards to be used in this course.

1 Capitalization

There are two capitalization styles we’ll use as we “name stuff” in our programs:

| Name | Description | Example |
| Camel Case | The first word starts with a lower case letter and all other words start with a capital letter. The rest of the letters are lower case. | weaponDamage |
| Pascal Case | All words start with a capital letter, with the rest of the letters in lower case. | NonPlayableCharacter |

The table below shows the proper capitalization style for the names of each kind of entity you’ll have in your programs:

| Entity | Capitalization |
| Class | Pascal Case |
| Field | Camel Case |
| Method | Pascal Case |
| Parameter | Camel Case |
| Property | Pascal Case |
| Local Variable | Camel Case |
| Constant | Pascal Case |
| Enumeration | Pascal Case |

Note: the variables that you’re declaring in your Main method (and all the other methods you write) are local variables. You should consistently follow this standard.

Peer Review Note: Although the standards above and the code I’ve provided to you names constants like WindowWidth (for example), most of the video lectures use all capitals and underscores (like WINDOW_WIDTH) for constants. Please give full credit in your peer reviews for both the WindowWidth and WINDOW_WIDTH capitalization approaches to constants.

2 Commenting

Documentation comment blocks (documentation comments start with ///) are used to describe the entities listed below. XML tags are used within the documentation comments.

Classes

Comment every class with a documentation comment block describing the purpose of the class. The comment block must start with the line ///.

Example

Enter to Rename, Shift+Enter to Preview

Methods

Comment every method with a documentation comment block describing the purpose of the method, the parameters passed in to the method (if there are any), and the value returned by the method (if there is one).

The purpose of the method is described in a summary, which should always come first, so the comment block for a method must start with the line ///.

Parameters are described using the param tag. The name attribute should be identical to the parameter name. The text between and describes what the parameter is used for. Each parameter gets their own param tag in the comment block.

The return value for the method is described using the returns tag. The text between and describes the return value.

Example 1

Enter to Rename, Shift+Enter to Preview

Example 2

Enter to Rename, Shift+Enter to Preview

Properties

Comment every property with a documentation comment block describing the purpose of the property. The comment block must start with the line ///.

Example

Enter to Rename, Shift+Enter to Preview

Line Comments

Every few lines of C# code you write should have a comment above them explaining what those lines are supposed to do. It’s not necessary to provide a line comment for every line of code, because that actually just ends up making things more confusing. There are no set rules about how much or little you should comment your code with line comments, but providing a line comment every 2-5 lines of code is probably a good rule of thumb. This is really about commenting”conceptual chunks of functionality”, but identifying those chunks really comes with experience.

Note: Some people have VERY strong opinions about how much to comment, or even whether or not to comment at all. On the other hand, all professionals are required to follow their organizational coding standards. Think of these guidleines for line commenting as the organizational coding standards for this course.

The format you should use for line comments is:

Enter to Rename, Shift+Enter to Preview

Example

Enter to Rename, Shift+Enter to Preview

By doing it this way, you’ll have easily-distinguished areas of line comments and the code described by the line comments.

3 Indentation

Indentation makes it easier to understand the structure of the code. Use the default indentation provided in Visual Studio, which is 4 spaces inside each block of code.

Example (comments excluded for brevity)

Enter to Rename, Shift+Enter to Preview

4 White Space

White space makes our programs much easier to read and understand. While it’s difficult to enumerate all the examples of good use of white space, use the code I provide from the video lectures as guidance.

One example, however, is that a single-line comment should ALWAYS have a blank line preceding it.

5 Variable Declarations

Although C# lets you declare multiple variables on a single line, you should only declare one variable per line in this course.

6 String Variables

We can use either string (lower case) or String (upper case) to declare string variables in C#. You should use whichever you prefer when declaring string variables. Make sure your class includes using System; at the top.

7 Statement Length

You can write statements that are arbitrarily long in Visual Studio (and most other IDEs), but that makes your code incredibly hard to read. Each statement you write must fit in the width of the default Visual Studio editing window. If you have a statement that won’t fit, break it up into multiple lines using concatenation (for strings) or at reasonable places in your arithmetic operations.

Example

Enter to Rename, Shift+Enter to Preview
https://www.coursera.org/learn/game-programming/supplement/ZvjcM/course-coding-standards