Transcript Good Coding Practice for Prototyping

Code Development
Code development
for end user
systems
Program Architecture
The organization of code
components
The objective of system architecture
is to simplify maintenance by
putting code together that will be
changed at the same time
Architectural Philosophies
Requirements Driven
 Data Driven
 Dialog Driven
 Event Driven

Coding Standards

Structured
Limit control structures to sequence,
iteration, and selection

Event Driven
Interactive systems driven by user
actions

Object oriented
Encapsulate data and code into objects
that can be called independently
Good Code
Maintenance is 80% of the cost of a
large system.
 Instructions that will be changed
together located together.
 Errors and bugs isolated.

Traditional Design

Traditional Life Cycle Approach
Formal Methodologies
CASE Tools
Purchased Systems

New Approaches
RAD
Evolutionary Code
GUI design
Object Oriented Design
Good Practice:
Loose Coupling
Associations among code modules




Data
Control
codes
Stamp
Hybrid
code
passes only data
passes data and control
passes information from
the structure of the data
one module changes the
in another
Good Practice:
Tight Cohesion
Functions done by one code module.
A module is a set of code
statements that is called and
executed together. A cohesive
module executes only statements
that always go together.
Typical Modules
Modules in identified files
 Macros and functions
 Forms, Reports and Queries
 Objects

Programming Principles

KISS (Keep it Simple, Stupid)
Volatility
Prototyped code will be revised
frequently. Simple solutions are much
better than elegant ones that are hard
to understand.
Clarity over Efficiency
EUC systems are usually elective and
not run as production code.
Programming Principles

Code should be written to be read
Good communication principles
White space
Boxes
Indentation
Explain complex logic
Modular construction
Very simple control structures
Mnemonic variables
Programming Principles

Minimize external
documentation
Document the objective rather than the
procedure. The next programmer can
find his own solution too.
Include descriptive and complete title
lines
Include an initial statement of program
purpose
Line comments hard to maintain
Programming Principles

Fully document data files
Use labels and file descriptions
Use original common data sources where
possible
Create as few original data tables as
possible
Document edits and modifications
Programming Principles

Retain natural documentation
Keep instructional memos and notes in
file
Document objectives so that modules
can be reprogrammed as needed
References
Weinberg, ‘Prototyping and the SDLC’, J Info Systems Mgt, 1991.
Chen, Nunamaker, Weber, ‘CASE: present status and future directions’,
Database, 1989