Notes 1:
Addendum to Essentials of Data Structures, Cpt 1

Math 61 -- D. C. Smolarski, S.J.
Santa Clara University, Department of Mathematics and Computer Science

Contents

• Introduction to Data Structures
• Planning for Programs

Introduction to Data Structures

This course concentrates on the foundational materials with which programs are written: Data Structures. It will look at questions such as: ``What is the best way to store information/data?'' ``What algorithms can be used to manipulate, retrieve, updata data?'' ``Which algorithms are best for which problems?''

It is not uncommon to find newspaper, journal articles, or web pages devoted to issues regarding "computer glitches" or "software reliability." (Try a web search via some search engine on the words "computer glitches" or "software reliability" (sample link) to see horror stories of near-disasters due to programming errors.)

Planning for Programs

• compilation errors: sometimes these are typos (e.g., mistyped variable names, misplaced brackets, omitted semicolons); sometimes these are due to incorrect syntax (e.g., using "then" in a C++ if statement).
• run-time errors: the program may compile, but when it runs, there are errors that prevent the program from completing normally (e.g., array index out of bounds may call abnormal termination);
• logic errors: the program may compile and run to completion, but the output is incorrect.

Suggested advance planning for completing programs on time.

• 6th day BEFORE due date:
  think about problem and write code by hand.
• 5th day:
  type code into computer file.
• 4th day:
  eliminate compiler errors.
• 3rd day:
  eliminate run-time errors.
• 2nd day:
  eliminate logic errors.
• Day before due date:
  Check final comments, and check to see if you have the correct output format.
• Day due:
  turn in.

Writing Longer Programs

When writing longer programs, i.e., programs with several functions / procedures / subprograms, try the following:

• use a "Top Down Approach" with "Successive Refinement" (i.e., write out general steps as the main code, and use each "step" as a function/subroutine call to be fleshed out independently);
• write the main program code in broad steps which determines the order of the entire code, but does not contain the details itself -- you should be able to look at the main code and figure out what the program does as a whole, but not seen the details;
• write, test, debug the component functions one-by-one -- i.e., get the main section and the first called function / subroutine working before trying to write the second function.