Introduction

This document was brought about by all sorts of students doing the wrong things in the Computer Methods pracs I take. If you're a student I have sent here, you can ignore the rest of this introduction. It basically explains the course and the pracs.

Computer Methods comes in two parts. CM1 is a first semester course designed to teach progamming to engineering students. The language used is Visual Basic (ugh!). CM2 is the second semester continuation of the course in which the students learn C in a linux shell.

The "practical" sessions take place four afternoons per week, and they exist for the students to get in some coding time and do any homework they've been given. On each afternoon, two demonstrators are available to help with any problems the students may have.

What the demonstrators are not here for

We are not here to teach you. That is what the lectures and the textbook are for. We can help clarify concepts or syntax for you, but you must show some kind of basic understanding first. This is not just because we're nasty. It's mostly because we don't have time to teach you the stuff you should have picked up in lectures.

We are not here to write your code for you. Don't ask us "How do I do X?" Try figure it out for yourself. Read your textbook. Browse the help files or man pages. We will happily answer questions like "I tried to do X, but it gives me result Y. Can you help me figure out what's wrong?" That shows that you have put in the effort yourself.

What we want to see

Preferably, we would like to see working code. Failing that, readable code will do. Here are some general rules for making your code readable:

Perhaps I should stress indentation a little more. Compare the difference between this (don't worry about what the code does if you don't know C):

#include <stdio.h>

int main()
{
    int i;

    for (i=0; i<10; i++) {
        printf("hello world!\n");
        printf("I am number %d!\n", i+1);
    }

    if (i > 10) {
        printf("This should never happen!\n");
    } else {
        if (i < 5) {
            printf("This should also never happen!\n");
        }
    }
}

And this:

#include <stdio.h>

int main()
{
int i;
for (i=0; i<10; i++) {
printf("hello world!\n");
printf("I am number %d!\n", i+1);
}
if (i > 10) {
printf("This should never happen!\n");
} else {
if (i < 5) {
printf("This should also never happen!\n");
}}}

Even in a trivial example like this, it is clear that the indented version is far more readable than the unindented version. Also, consider what happens if you leave off a closing brace somewhere. In the indented version it is far less likely to happen and far easier to find if it does. More than half the problems I have to solve for students in CM pracs involve missing or misplaced block delimiters -- don't be one of them.

Variable and function names are very important. Which of these two code blocks makes more sense?

#include <stdio.h>

void foo(int x)
{
    printf("The answer is: %d\n", x);
}

int bar()
{
    int x;
    printf("Please enter a number: ");
    scanf("%d", &x);
    return x;
}

int main()
{
    int x, y, z;
    x = bar();
    z = x;
    for (y=1; y<x; y++) {
        z *= x;
    }
    foo(z);
}
#include <stdio.h>

void print_result(int result)
{
    printf("The answer is: %d\n", result);
}

int get_input()
{
    int input;
    printf("Please enter a number: ");
    scanf("%d", &input);
    return input;
}

int main()
{
    int operand, result, i;
    operand = get_input();
    result = operand;
    for (i=1; i<operand; i++) {
        result *= operand;
    }
    print_result(result);
}

Of course, commenting what each block is supposed to do makes it even more readable:

#include <stdio.h>

void print_result(int result)
// This function tells the user what the answer is
{
    printf("The answer is: %d\n", result);
}

int get_input()
// This function asks the user for a number and returns an integer
{
    int input;
    printf("Please enter a number: ");
    scanf("%d", &input);
    return input;
}

int main()
{
    int operand, result, i;
    // Get user input
    operand = get_input();
    result = operand;
    // Here, we raise the number the user gave us to itself
    // For input 3, we get 3 to the power 3 => 27
    for (i=1; i<operand; i++) {
        result *= operand;
    }
    // Display output
    print_result(result);
}

Comments can be added after a block is written (although many people find it easier to write the comment first to clarify in their minds what the block does) but indentation and meaningful names must be part of the code. After writing good code for a while, it becomes habit. Writing bad code, however, is also habit-forming. Choose to develop good habits early on and you will have few problems later.

Marking

If we are marking pracs, there are a few extra things to consider. First, don't leave everything to the last minute. There are (at the time of writing) over 250 students in the class and only 2 demonstrators per afternoon. If more than half the class arrives on the last Friday, there is no way we will get through everybody. There is a reason we allocate two weeks for marking.

If you have been asked to bring a hardcopy to be marked, don't come to us without it. Please ensure that your name is on it and that it is stapled if it is more than a page. We are not going to waste our time tracking down idiots who haven't given us their names.

Don't copy code from each other. Even if you do manage to get away with it, it's not going to help you. The only way to learn programming is to do it, and you will need it later in your degree.

General advice

Think about what you are trying to achieve before you start writing code. An hour spent planning can save three or four hours debugging and rewriting, and generally leads to better code as well.

Instead of trying to handle a given problem as a special case, see if there's an easy way to generalise it. Use loops instead of explicitly doing the same thing several times.

Avoid arbitrary limits, if you can. Why restrict the user any more than you have to? What would it be like if your word processor only let you write three and a half pages? That said, enforce the limits you need rigorously. Most people would rather get a message asking for a smaller input than have your program crash halfway through.

Google Is Your Friend. If you can't figure out how to do something, or the textbook and help files can't help you, search the web. Just make sure you understand anything you stick into your code, otherwise you can end up with huge debugging problems.

Don't think that this course will automatically make you a good (or even reasonable) programmer. As with all things, you get out what you put in. For more on this subject, read what Peter Norvig, Director of Search Quality for a company you have probably heard of, has to say on the subject of learning programming. You can find his essay here.