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.
* 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.
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
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
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
If it's true the brain is like a computer, then there aren't really any stupid people.
- Ali Rezazadeh
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....]);
eg
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....])
{
...
}
eg.
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
parameters:
f() function to be integrated
a lower limit of integration
must be positive
b upper limit of integration
must be greater than a
returns:
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>