5: Input and output, and good programming.

5.1 Files and records.

So far we have been reading input from and writing output to the terminal. More generally we may wish to read our input from a file on disk, and output

results to another file on disk or the printer. Every file consists of records which are lines of information in the file that are terminated at the end of the line by carriage return. Each line of numbers you type in at the terminal with return at the end (for input to a program) is one record. A file then comprises a sequence of these records.

Records are read from the terminal using the READ* statement and written to it by the PRINT* statement. FORTRAN regards each one of the channels, to or from which information is transferred, as units, and each one has an associated unit numbers. This can be seen if we use the explicit form of the READ* and PRINT* statements:

	READ(5,*)	read from unit number 5 (which is the keyboard)

	WRITE(6,*)	write to unit number 6 (which is the screen).

The * is where the format is specified and means, as before, list-directed output. A number here would mean a FORMAT statement label.

The allowed range of unit numbers is usually 1 to 99. 5 is normally associated by the computer with the keyboard, and 6 (often 5 as well) with the screen. Other numbers are assumed to be for disk files.

Thus if I want to write some results to a disk file, the following statement would do:

	WRITE(20,10)RES
    10  FORMAT(' THE RESULT IS ',F10.4)

When this statement was executed the computer would create a file on your disk called fort.20 (the exact file name will vary from computer to computer) - FORTRAN file associated with unit 20. In the file would be one record:

	THE RESULT IS  1045.0342

If later on in the same program you wrote to unit 20 again:

	WRITE(20,20)N
    20  FORMAT(' THE NUMBER OF ITERATIONS WAS: ',I4)

Then fort.20 would contain:

	THE RESULT IS  1045.0342
	THE NUMBER OF ITERATIONS WAS:   23 

In a similar way, it is possible to read from a disk file with filename fort.15 using unit number 15 in the READ statement:

If fort.15 contained the 2 records:

	12,8,16.453
	10.00,134.321

then

	READ(15,*)N,I,RES
	READ(15,*)E,R

would transfer the information in record 1 into N, I and RES; and record 2 into E and R.

You can explicitly make FORTRAN read from filenames other than the default fort.nn by the use of the OPEN statement. This associates files or devices with a unit number and overrides any defaults the system may have. Thus you could write the above information on unit 20 to a file called results.dat:

	OPEN(UNIT=20,FILE='results.dat')		note use of single quotes for the character string
	.
	.
	WRITE(20,10)RES
	.
	.
	WRITE(20,20)N
	.
	.
	CLOSE(UNIT=20)

When you've finished writing to the file it is good practice to CLOSE the file. Once you've done this the FORTRAN program no longer has unit 20 associated with file results.dat, and so you are free to use unit 20 again for something else.

It is also possible to read in a filename when your program is running and use this filename in an open statement:

      CHARACTER*10 FILENM
      WRITE(6,*)' ENTER THE NAME OF THE RESULTS FILE'
      READ(5,10)FILENM
  10  FORMAT(A10)
      OPEN(UNIT=21,FILE=FILENM)		note the character variable is not in quotes.
 	.
	.

If the file already exists it will open it ready for reading from or writing to. In the case of writing data into the file, any previous data in the file before it was opened will be overwritten! If the file doesn't exist then it will be created ready to be written to. Now if you try to read data from it that isn't there you will get an end-of-file error!

5.2 Good programming practice

There are some general principles about the design of programs that should be a goal towards which we should all strive in our programming. These are:

  1. free of design errors;
  2. rapid to test;
  3. easy to understand;(good style);
  4. straightforward to modify; (not convoluted)
  5. unlikely to require complete rewriting;
  6. robust;(well error-trapped)
  7. efficient;
  8. portable;(keep to language standard)
  9. well documented.

These are equally relevant whether we are writing a small program or a large program of many thousand lines of code. The benefits of this approach can be very great. It is possible to write a program that is so contorted and opaque, that no-one but the author (and even the author as time goes by) can understand it.