A flowchart is a graphic illustration of the steps to follow in order to arrive at the solution to a problem. It is a program design tool that you use prior to writing the actual program.

A flowchart consists of a set of various standard shaped boxes that are interconnected by flow lines. Flow lines have arrows to indicate the direction of flow of control between the boxes. The description of the activity within the boxes is written in English. In addition, there are connector symbols that are used to indicate that flow of control continues elsewhere, for example, another page.


* Flowcharts are to be drawn on white, unlined 8 1/2" x 11" paper on one side only.

* Your name, student number, the number of the assignment and the title of the program must appear at the top of each page, along with the page number.

* Use only standard flowcharting symbols (see following page).

* Use a template to draw the final version of your flowchart.

* Print the contents of each symbol legibly.

* Use English, not programming language statements, in flowcharts.

* If your flowchart includes subroutines the flowchart for each subroutine must appear on a separate page. Each subroutine begins with a terminal symbol with the subroutine name and a terminal symbol labelled return at the end.

* Flowcharts start on the top of the page and flow down and to the right.

* Draw arrows between symbols with a straight edge and use arrowheads to indicate the direction of the logic flow.


Symbols are on the following page.


The following passages list some words of wisdom on programming principles (life?). Some "rules" are contradictory, but that's the point. Always remember: Every rule has an exception; including this rule.

If it ain't broke, don't fix it.

- Grandpa

If it works it's obsolete.

I would rather write programs to help me write programs than write programs.

- Dick Sites, DEC

Sure, 90% of all software is crud. That's because 90% of everything is crud.

- Mary Shaw, CMU

If you lie to a computer it will get you.

- Perry Farrar

Common sense is not so common.

- Albert Einstein

2.2.1. DESIGN

KISS it. (Keep It Simple Stupid.)

Understand the problem. The best design is often the simplest.

- Jon Bentley, Bell Labs

A design that does not fit on one 8.5-by-11 inch paper cannot be understood.

- Mark Ardis, Wang

When in doubt use brute force.

- Ken Thompson, Bell labs

Let the data structure the program.

-David Parnas

Design data structures first; rest of the program will write itself.

- David Jones

Avoid arbitrary restrictions. The only reasonable restrictions are 0, 1, and [[infinity]].

It is often easier to derive a general solution than for a special case.

Experience is what you get when you don't get what you want.

Good judgement comes from experience, and experience comes from bad judgement.

- Fred Brooks


Plan for deadlines. The sooner you start to code, the longer time it takes.

Don't keep doing what doesn't work.

Furious activity is no substitute for understanding.

- H. H. Williams

Prototyping cuts the work to produce a system by 40%.

- Larry Bernstein, Bell Communication Research

Plan to throw away one prototype. You will anyhow.

- Fred Brooks

Good customer relations doubles productivity.

- Larry Bernstein, Bell Communication Research

Beware of claims that "it's 95% complete".

The first 90% of code accounts for the first 90% of development time. The remaining 10% of code accounts for the other 90% of development time.

- Tom Cargil

Respect standards: when in Rome, don't do as the Greeks do.

- Grandpa


Strive for orthogonality; keep unrelated features unrelated.

- Jon Bentley, Bell Labs

Details count.

- Peter Weinberger, Bell labs

Make a user interface as consistent and as predictable as possible.

Avoid too many special cases.

Provide tools. Make them general. Use the right tool for the job.

- P.J. Plauger, Yourdon Inc., Brian Kernighan, Bell Labs

When the only tool you have is a hammer, everything looks like a nail.

- Henning Mortensen

2.2.4. CODING

If you can't write it down in English, you can't code it.

- Peter Halpern

Avoid asymmetry.

- Andy Huber, Data General

Modularize. Remember 7 +/- 2.

Brevity is the soul of wit.

- The Bard

The code for a module should fit on a screen.

Why reinvent the wheel? Use library functions whenever possible.

Handle normal cases and worst cases separately.

Store dates internally as YYYYMMDD. A new millennium is coming.

Know your limits. Remember September 28, 1989.

Everything should be made as simple as possible, but no simpler.

- Albert Einstein


Avoid bugs in the first place. An ounce of prevention is worth a pound of cure.

Testing shows the presence of bugs, not their absence.

- Edsger Dijkstra

Make up exhaustive test data during design and coding.

The first step in fixing a problem is getting it to fail repeatedly.

- Tom Duff, Bell Labs

80% of bugs are syntax errors. Of remainder 80% are trivial logic errors. Of remainder 80% are pointer errors. Remaining .8% are hard.

- Marc Donner, IBM

If the code and comments disagree, both are probably wrong.

- Norm Schryer

Debug the code. Don't be led astray by the comments.

Don't debug standing up. It reduces your patience.

- Dave Storer


No job is over until the paperwork is done.

When explaining anything, first describe the problem it is designed to solve.

- David Martin

Be consistent in your style. Choose one format and stick to it.

Strive for "self documenting" code and data.

Don't over decorate. Avoid over-documentation.

Black and White Rule: Use white space effectively. In a sea of white your eyes will spot the black. In a sea of black your eyes will catch the white.

A picture is worth a thousand words.

Graphics is only screen deep.

- Rob Andrews, BNR


Don't use a computer to do things that can be done efficiently by hand.

Don't use hands to do things that can be done efficiently by a computer.

Get it to work first. Then make it work faster.

- Jon Bentley, Bell labs

Before optimizing, use a profiler to locate "hotspots".

- Jon Bentley, Bell Labs

In allocating resources, strive to avoid disaster than to attain an optimum.

- Butler Lampson

In non-I/O-bound programs, less than 4% of a program generally accounts for more than half of its running time.

- Don Knuth

80-20 rule: 80% of the world's resources are consumed by 20% of the population.

Premature optimization is the source of much programming evil.

- Don Knuth

2.2.8. Pièce de résistance

If it's true the brain is like a computer, then there aren't really any stupid people.

- Ali Rezazadeh

2.3 C Programming style:

1. Put all prototype definitions into a header file, eg. file.h.

2. Prototype definitions should be of the form:

type name(vartype variable [,vartype variable....]);


int func1(int i, float fvar, char **names);

3. The first line of a function definition should match the prototype exactly (except for the semi- colon).

type name(vartype variable [,vartype variable....])





int func1(int i, float fvar, char **names)




4. The function main should always return 0 upon normal termination.

5. All braces should be on lines by themselves.

6. All control structure bodies should be indented one tab stop.

7. Debugging statements may be left in code if surrounded by #ifdef. For example use #ifdef DEBUG to include print statements within the body of the program for debugging. Debugging statements should appear in the functions being debugged, ie print the return value in the called function not the calling function, if possible.

8. All files should be documented. The form should be:


Filename: func.c

Author: Your Name

Student #: 184 101 111

routines: func1,func2,func3


9. All major functions should be documented. The form should be


Function name: func

Purpose: Return the result of the integration


f() function to be integrated

a lower limit of integration

must be positive

b upper limit of integration

must be greater than a


Result of the integration


NOTE: function and file documentation can be combined if a file contains only one function.

10. Do not use macros to create obscure code but use them to define any constants or frequently used constructs.

ie: Do not use macros such as:

#define float int

That obscure the function of program.

Do use macros such as:

#define MAXLEN 255

#define PIE (acos(-1))

#define NEW(x) (x *)malloc(sizeof(x))

which enhance the readablity of the program.

11. Global variables should be avoided where possible. Always start the name of a global variable with a capital letter. For example:

int Counter

12. No goto statements are allowed.

13. Use library functions wherever possible. Always include header files for libraries; eg:

#include <stdio.h>

#include <signal.h>