All files will start with a header comment. This is just a comment that contains:

• A description of what the file is for or what the program does,
• The names and zIDs of everyone who worked on the file,
• Your tutor’s name, and
• The date that the file was made, in the form YYYY-MM-DD.

Suppose the student Julian Saknussemm was working on a program that simulated an ant farm, the header file for the antFarm.c file would look something like the following.

#includes are how we use code from other files in our .c files so that we can share functions between files. #includes always come after the header comment.

System includes, which use < and > and look like #include <stdlib.h>, are used to include header files that are installed on the operating system. These should be in alphabetical order and should come first.

Local includes, which use " and look like #include "myModule.h", are used to include our own header files. These should also be in alphabetical order and should come after system includes.

Constants are created using #define and allow us to create constant values with a name. We give these values a name near the start of our file and then we can use the name in the rest of the file. This means that if we want to change the value at any point, we only need to change it once.

If we want to use any mathematical operators in our constants, we need to surround everything with parentheses. #define can also be used to make constants with floats, chars, and strings.

Programs tend to be written in a top-down manner. This means we start at the top, at the highest level of abstraction, and progressively descend through the levels. Usually, the main function is the highest level of abstraction: the place where the program commences.

When we compile and link a program, the main function is assumed to be the place where that program’s execution starts. By convention, it takes two parameters: the count of command-line arguments, argc, and the length of the command-line argument vector, argv. These names, argc and argv, are conventions followed by most C programmers.

A general rule with file structure is that no line should be more than 72 characters wide. This means we will be able to read it in most text editors more easily.

For functions, the opening brace ({) should be on the same line as the function prototype. The closing brace (‘}’) should be on its own line and not indented.

For if, the opening brace (‘{‘) should be in the same line as if and the loop condition. The closing brace should be on its own line and should line up with the i in the matching if.

For else and else if, the else should be on the same line as the closing brace (}) before it. The opening brace ({) should be on the same line as the else, or the else if and the condition. The closing brace (}) should be on its own line and should line up with the closing brace (}) before it.

For loops, the opening brace ({) should be on the same line as while and the loop condition. The closing brace (‘}’) should be on its own line and should line up with the w in the matching while.

Variables tend to belong to the area of code that declares them, an effect known as scope. In C, it’s valid to have variables declared in the global scope. However, this is considered bad practice and should be avoided, as values in global variables may cause unintended effects in functions.

The static qualifier has a very different effect on variables to the effect it has on functions. Values in static variables persist across multiple calls to the function, which is even more insidious than global variables for introducing unintended effects.

C allows us to jump to arbitrary locations in our program. You can see why that might be a terrible idea: there’s no guarantee that one line of code would follow another.

Unlike some other languages, C is a statement-oriented language, so an if statement doesn’t have a value. A ternary allows us to produce different values depending on a particular condition. Ternaries are a very, very easy way to produce really confusing effects, and you shouldn’t use them.

The break and continue keywords can change the logical flow of control in loop statements, with the effect that the body of a loop may not proceed from top to bottom under all circumstances. It can be confusing and bizarre, and under all circumstances (that you encounter in COMP1511) you should reconsider your logic instead.

The do { ... } while (condition); construct is similar to a normal while (condition) { ... }, except the body will always run before a condition is checked. It’s very easy, to construct do...while expressions that are confusing and poorly structured, and in COMP1911 we prefer to avoid them.

If you have a function that performs two smaller tasks in sequence, make a function for each of those smaller tasks and call them from the more abstract function. Aim for your functions to be less than 20 lines or less. If they are long, think of how you can break them up into smaller functions.

Function prototypes describe functions be telling the compiler (and anyone reading the program):

• The type of value the function returns
• The name of the function
• The type and name of any arguments to the function

A space may optionally be used between the function name and argument list and the function name. The return type, function name, and start of the argument list should all be on the same line. If the argument list is too long to fit on a single line with the function name and return type, it may be split across multiple lines, with the additional lines being indented by 2 stops (8 spaces) or aligned with the first argument in the first line. Function and argument naming is discussed in the functions section of this document.

Pointer arithmetic is one of the stranger features of C. Pointers are, of course, numeric values, so in theory, you can manipulate them as you would any other number. In practice, though, changing pointers yourself is a bad idea, and is likely to cause serious problems.

One of the more common places we often see pointer arithmetic is string manipulation: a lazy programmer might say *string++, to get the current character in the array string, while also moving it along to the next value. This changes string, of course, meaning you lose the beginning of the string. Indirectly, the ++ is pointer arithmetic: it’s the addition of one to the value.

This is, in and of itself, fairly harmless, but ++ or +1 may not have the effect you expect if a value would take up multiple bytes. Instead, it would step along by the size, effectively emulating the behaviour of [] but being more confusing.

You should always access array elements using index notation, [].

You can point at literally everything in C, even the functions you write. Function pointers are fairly dangerous, as they make it very easy to cause your program execute arbitrary code that may not be the code you expected. For the security implications alone, they’re banned.

Another, more subtle trick is the use of function pointers as a poor-man’s generic programming; that’s not ever needed in this course, so we can safely ban it.

We can create structured data using structs, which help us define a collection of related pieces of data. These allow us to contain several different values of different type in one value that can be passed around. These should always be defined after constants.

The names of struct tags must be in camel case starting with a lower-case letter. A struct should always have an associated typedef so that it can be used more cleanly as a type. The type name should be the same as the struct tag, but with the first letter in capitals.