C for Yourself - part 2

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);


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

In C, there are two types of instructions: statements and declarations. Before a variable - or a function - can be used, it must be declared.

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

Often you will want to group C commands together, for instance inside a loop, as part of an if statement of in a function. To do this, the statements are enclosed within braces, { and }.

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 are ignored by the compiler, and are used to remind you or anyone else about the salient features of a piece of code.

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

Preprocessor instructions, as explained last month, are executed before the program compiles. They can occur anywhere in a program, but are commonly bunched up at the start. They all start with a # character, for instance:

#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"

It is good practice to scatter comments liberally throughout your code. Not only does this enable other people to follow what you are up to, it serves as a reminder to you, and makes the code much easier to debug.

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.

Source: Acorn User - 146 - September 1994
Publication: Acorn User
Contributor: David Matthewman