This month David Matthewman explains the syntax of the C language.

Although the syntax of the language C is fairly straightforward, it is worth getting to grips with it before attempting to write complicated programs.

Like Basic, C programs are made up of a list of instructions. In Basic, instructions are separated either by a newline character or by a colon.

In C, instructions may flow over several lines, so the newline character cannot be used.

Instead, C instructions are separated by a semicolon, which must be present. There may be many instructions on one line, and one may flow over several lines. For instance:

hyp = x*x
    + y*y
    + z*z;
len = sqrt(hyp);

and

hyp = x*x + y*y + z*z; len = sqrt(hyp);

are equivalent legal pieces of C code: the newlines are effectively ignored.

Statements and declarations

This is similar to a DIM statement in Basic, as it reserves memory for the variable, but unlike Basic it must be done for every variable and function used in the progrm.

The declaration also establishes the type of the variable: integer, real, pointer and so on.

This is the purpose of the header files mentioned last month; they declare the standard library functions.

We will look in more detail at what variable declarations are available, but the for the moment it is sufficient to know that they generally occur at the start of functions or program fragments and have the form:

<var_type> <var_list>;

where the variable type is a word such as int, char, float or struct, to name but four. Many variables of the same type may be declared in one instruction by separating them with commas, but the instruction must end with a semicolon.

Statements are more familiar instructions to the Basic programmer. These are the ones which actually do something: variable assignments, loops, if statements, functions and so on.

Instructions may be labelled. A labelled line has the form:

label : instruction;

and is generally used in conjunction with the dreaded goto statement. However, labels are also used with the switch statement, and there is nothing to stop them being used to break up the code and act as a primitive form of comment.

Grouping commands

All individual statements within the braces must end with a semicolon, but there is no need for a semicolon after the last brace.

Conventionally, each time an opening brace is used, the text in the source is indented.

The text is un-indented by a similar amount for each closing brace. This is not enforced by the C compiler, but it is good practice as it makes it much easier to match opening and closing braces.

Many text editors, StrongEd for instance, have a facility to match braces automatically.

When a closing brace is typed, the editor will briefly move the cursor to the corresponding opening brace, or beep if no opening brace can be found.

Comments

They can also be used to temporarily remove - 'comment out' - a fragment of code which you do not wish to be executed when testing a program.

In C, comments are started by /* and ended by */. Any text between these two character sequences is treated as a comment and ignored by the compiler. Nested comments are not allowed, so for instance:

/* This is a /* nested */ comment */

will make the compiler unhappy.

You cannot put comments inside strings either. The compiler will not recognise them as comments and will treat them as part of the string.

Comments do not require a line of their own, and unlike Basic REM statements, comments may also be followed by statements on a line.

It is good practice to align a series of comments so that they start from the same position on the line, as this makes it easier to see what is and is not comment.

To the C compiler, of course, this is irrelevant, but there are plenty of reasons for writing well-commented code.

Preprocessor instructions

#include <stdio.h>
#define TRUE 1

As you can see, unlike standard C instructions, pre-processor one are ended with a newline character rather than a semicolon.

However, if the last character on a line is a backslash, '\', the line is concatenated with the next line, so they may be split over several lines if they are too long to fit on one. Only one instruction is allowed per line, however.

By now, you should have enough knowledge about the syntax of C to be able to look at a C program and say 'this is a comment' or 'that line will be interpreted by the preprocessor', even if as yet you won't have a clue what the program actually does.

This is vitally important: until you know how to parse a C program correctly, it can be a daunting jumble of characters which appear not to make much sense.

Next month I will take a first look at variables, with a discussion of what types are available in C and an examination of some of the operators available to manipulate them.

Sidebox: "Well commented code"

In practice, hardly anyone uses comments to the extent that they should. There are a number of reasons for this:

Mystique. Programmers who have just written a particularly neat, concise or gnomic piece of code my feel that - like a good joke - it will be spoiled if they explain it.

Haste. Writing comments is time consuming and, as comments add nothing to the actual operation of the program, many programmers feel that their time could be better spent.

Hubris. It is beneath programmers to comment their code; any gibbon can do that. Writing manuals is similarly looked down upon, as in some cases is creating a decent user interface.

Memory. Many programmers who started life programming a ZX80 get worried by the tendency of comments to double the size of a C source file. These people also never indent their code, use variables with names like 'a' instead of 'template_file_handle'm and tend to use 'INT(PI)' instead of '3' to 'save a byte of storage'.

There's no excuse for you to do the same, though.