Week 1 - General Coding Style Guidelines

There are many coding style guidelines in the IT industry, but they all have some common attributes. These attributes, plus a few appropriate for an academic atmosphere, will be used in this course.

MARKS WILL BE DEDUCTED for not following the course guidelines on all submissions.

General Rules

Ensure that clarity, readability and transparency are always prioritized.
Do not reference unnecessary libraries, include unnecessary files, or reference unnecessary assemblies that are not actually used in the code.

Layout Conventions

Indenting will consist of 4 spaces or a standard tab.
Write only one code statement per line.
Write only one declaration per line.
Include at least one blank line between class, method, and property definitions.
Use parentheses to clarify order of precedence if an expression is large or unclear.

Commenting Conventions

Comments are to be written in English with correct spelling and grammar
Most of the time, comments should be on a separate line from the code. Only place comments at the end of a code line for obvious code structures, like conditional statements (IF, ELSEIF, CASE, SELECT, etc...)
Provide at least one space between the coding syntax and the comment itself
(example: // There is one space between the slashes and the text.)
ALL files, classes, methods, and properties should have comment headers with the following information:
- Files - include title, author, date, and purpose along with an optional version number.
- Classes - include a description and any versioning comments
- Functions and Methods - include the title, description, and a list of parameters with their meaning, data type, and intention. Any external dependencies should be clearly documented.
- Properties - include a description of the meaning intention of the property
Use commenting conventions appropriate for the language of choice:
- Triple slash "///" for C# for XML documentation
- JavaDocs for Java

Declarations and Data Type Conventions

Declare local variables in the minimum scope block that can contain them, at the top of that scope
block.
In general, use integers (int) for whole numbers rather than unsigned or size-specific types.
(Unsigned Data Type)
In general, use the double data type for decimal values rather than float or other size-specific
types. The decimal data type may be used if higher precision is necessary

Naming Conventions

Always favour readability over brevity
Do not use underscores, hyphens, or other non-alphanumeric characters for naming.
Do not use hungarianNotation for variable names objects outside Form Control Objects.
Avoid abbreviations and contractions in identifier names (e.g. GetWindow instead of GetWin,
temporaryEmployee instead of tempEmp, average instead of avg, etc.)
Use meaningful names for variables, constants, functions, classes, and data structures. All names
should make the identifier’s purpose immediately clear.
Use the ‘is’ prefix for Boolean/Bit variables and methods, e.g. isSet, isOpen, isValid, etc.
Acronyms should not be uppercase when used as part of a name, e.g. use exportHtmlSource, not
exportHTMLSource.
Methods should be verbs, in camelCase with the first letter lowercase, with the first letter of each internal word capitalized

The following table describes the capitalization and naming rules for different types of identifiers:

Identifier	Casing	Code Example
Class, Structure	PascalCase	`class Vehicles {}`
Method, Function	verb based camelCase	`private void convertCase() {} private String getUserName(String userID) {}`
Parameter, Variable	camelCase	`int userID = 0;`
Constant	ALL CAPS with snake_case	`double TAX_RATE = 13.0;`
Property, Field	camelCase - local scope	`private String userName;`
Form Control Object	Hungarian Notation with camelCase	`textBox txtUserName as New textBox();`

Other Industry Standard Style Guidelines