1.3. Source Files

The function definitions, global declarations and preprocessing directives make up the source code of a C program. For small programs, the source code is written in a single source file. Larger C programs consist of several source files . Because the function definitions generally depend on preprocessor directives and global declarations, source files usually have the following internal structure:

C supports modular programming by allowing you to organize a program in as many source and header files as desired, and to edit and compile them separately. Each source file generally contains functions that are logically related, such as the program's user interface functions. It is customary to label C source files with the filename suffix .c .

Examples 1-2 and 1-3 show the same program as Example 1-1, but divided into two source files.

Example 1-2. The first source file, containing the main( ) function

// circle.c: Prints the areas of circles.
// Uses circulararea.c for the math

#include <stdio.h>
double circularArea( double r );

int main( )
{
  /* ... As in Example 1-1 ... */
}

Example 1-3. The second source file, containing the circularArea( ) function

// circulararea.c: Calculates the areas of circles.
// Called by main( ) in circle.c

double circularArea( double r )
{
  /* ... As in Example 1-1 ... */
}

When a program consists of several source files, you need to declare the same functions and global variables, and define the same macros and constants, in many of the files. These declarations and definitions thus form a sort of file header that is more or less constant throughout a program. For the sake of simplicity and consistency, you can write this information just once in a separate header file, and then reference the header file using an #include directive in each source code file. Header files are customarily identified by the filename suffix .h . A header file explicitly included in a C source file may in turn include other files.

Each C source file, together with all the header files included in it, makes up a translation unit . The compiler processes the contents of the translation unit sequentially, parsing the source code into tokens , its smallest semantic units, such as variable names and operators. See the section "Tokens," at the end of this chapter for more detail.

Any number of whitespace characters can occur between two successive tokens, allowing you a great deal of freedom in formatting the source code. There are no rules for line breaks or indenting, and you may use spaces, tabs, and blank lines liberally to format "human-readable" source code. The preprocessor directives are slightly less flexible: a preprocessor directive must always appear on a line by itself, and no characters except spaces or tabs may precede the hash mark (#) that begins the line.

There are many different conventions and "house styles" for source code formatting. Most of them include the following common rules:

• Start a new line for each new declaration and statement.

• Use indentation to reflect the nested structure of block statements.