APS105H: General Assignment Guidelines

Overview

This page contain general information that is applicable to all assignments, unless indicated otherwise on the assignment handout. Please read it carefully, and note that new items will be added (clearly marked as "new") as the assignments increase in complexity. Failure to follow these instructions may result in deductions.

The requirements on this page are divided into two categories. The first set are general principles that lead to better, more understandable code. The second set are a list of specific code formatting requirements. The reason we have formatting requirements is that consistent style is essential to maintainable code. It is also good preparation for real-world programming -- all organizations have style guides that dictate how their programmers should format code. The need for this becomes clear if you think about what would happen if many (e.g., hundreds) of programmers were working on the same program, but each was formatting it slightly differently. Style is (to some extent) a matter of personal preference, and in many cases there are several alternative formats that are equally readable. For the sake of simplicity, the style guidelines that we have selected for this course generally mirror the code examples found in Carter.

Section 1: General Instructions

Your code should compile cleanly. This means that there should be no compiler errors or warnings.

Your code will be evaluated on ECF. You are welcome to work on your own computer at home, but if you do so you should allocate time to test (and potentially debug) your program on ECF. One option is to work from home via ssh, which allows you to connect to ECF remotely.

All files should begin with a comment that contains your name, student number, and a brief summary of what the file does (i.e., describes the purpose of the code in the file).

New for A2: Your variables should have meaningful names, and should follow the naming conventions we use in this course. This means that normal variables should start with a lower case letter and use CamelCase to indicate the start of each word (e.g., numStudents), and constants should use upper case letters and separate words with underscores (e.g., NUM_PROFS).

New for A2: There should be no magic numbers in your code. Instead, you should use constants with meaningful names.

New for A2: When applicable, you can use C99 features (e.g., declaring an index variable in the initialization statement of a for loop), and you can assume that your code will be compiled by us with the -std=c99 option.

New for A2: You may not use 1 and 0 in place of true and false.

bool isOpen = true;

bool isOpen = 1;

New for A2: You should not treat true and false as if they were ints.

bool areBothTrue = (b1 && b2);

bool areBothTrue = (b1 + b2 == 2);

New for A2: You are not permitted to use break or continue unless directed otherwise.

New for A3: You are not permitted to use gets(). Any submission that uses gets() will receive a significant deduction. Instead, you should use fgets().

New for A4: You are not permitted to use strcat() or strcpy(). Any submission that uses either function will receive a significant deduction. Instead, you should use strncat() or strncpy().

New for A4: All memory obtained from malloc() must be cleaned up using free().

Section 2: Style Information

Each brace (a.k.a curly bracket) should be on its own line.

int main(void)
{
...
}

int main(void) {
...
}

Blocks of code should be indented 4 characters using spaces. Most text editors will either do this automatically when you hit the tab key, or can be set to do so.

int main(void)
{
    return 0;
}

int main(void)
{
return 0;
}

int main(void)
{
        return 0;
}

Binary operators should have spaces around them. Unary operators should not.

int i = 2;
i = i + 3;
i = -i;

int i=2;
i=i+3;
i = - i;

Your .c files should end with a single blank line.