1

CMSC 345

Programming

2

Topics

Work Breakdown Coding Standards Defensive Programming Structured Programming Documentation

3

Work Breakdown

Be positive that all component (e.g., objects, functions) interfaces are crystal clear to all team members

Based on these interfaces, divide the work into independent, manageable pieces among team members

One team member in charge of configuration management and change control wrt interfaces; no changes w/o his/her approval

One team member in charge of code checkin/checkout and file directory structure

One team member in charge of integration planning, keeping abreast of any changes in interfaces and/or source code files (above)

4

Work Breakdown (con’t)

One team member charge of tracking that everyone is doing what they’re supposed to do and is on schedule; should be in daily contact with all team members

One team member in charge of “master copy” of SRS and keeps track of changes, informing others of changes

One team member in charge of “master copy” of SDD and keeps track of changes, informing others of changes

5

Coding Standards Everybody’s got them - a very real-

world thing They help you organize your

thoughts and avoid mistakes They let you focus on the problem You must organize, format, and

document your code to make it easy for others to understand

6

Coding Standards -Problems Without Them

Computer programs are generally more difficult to read than to write (even one's own code is often difficult to read after it hasn't been looked at for a while).

Software that is not internally or externally documented tends to be thrown-away or rewritten after the person that has written it leaves the organization (it is often thrown-away even if it is documented).

7

Coding Standards -Problems w/o Them (con’t)

It is often more difficult to reuse software someone else has written than to rewrite it your self because it is hard to figure out how it works.

In practice, debugging often takes the place of understanding how programs work (ie., if we all understood perfectly how our own code worked we would not need to debug it to find out why it is not doing what we think it should).

8

Your Coding Standards Establish team coding standards

immediately and document them file header comments function and/or object commenting coding and commenting styles identifier naming conventions

Later code inspections will check for this as well as correctness

Makes easier to debug/maintain, particularly by others – not the original author nor even original team members

9

Defensive Programming - General Check validity of all input parameters

(e.g., within range, non-null) Check validity of all returned values (i.e.,

from called subroutines) Repeatedly check validity of all external and internal data structures or data files

Segregate this code so can easily be commented out during performance tuning (if tuning is necesssary)

10

Defensive Programming -Validate All User Inputs

Expect the unexpected - and be able to recover!

Respond to bogus inputs with useful diagnostics when possible, and explain what would be valid input in each case

When there is a default value, indicate in the prompt and accept blank input to defer to the default value

When there is a choice among a small number of simple values, list all of them in prompt

11

Defensive Programming - User Outputs

Clearly explain all user output along with the output value(s)

Provide options for at least two levels of verbose and terse output modes (also applicable to prompts)

Probably also testing/debug mode (for use by test drivers or scripts)

If the user has to “wait”, give a periodic visual cue that the program is busy working (rather than hung)

When possible, trap fatal errors and give diagnostics (including how to recover and who to report bug to)

12

Structured Programming

Regardless of the programming language, each program component involves at least Control Structures Algorithms Data Structures

13

Control Structures

Keep them as top-down as possible - no “spaghetti code”

Are a good clue as to when a comment is needed

14

Algorithms Keep them as generic as possible (for reuse

within same program or with later program(s))

Fast code is overrated and has cost (it’s complex!) Takes more time to write Takes more time to test Takes more time for users to understand Takes more time to modify and debug

Execution time is only a small part of the cost equation. Balance execution time with design quality and customer requirements

DO NOT sacrifice CLARITY and CORRECTNESS for speed

15

Documentation

Internal Documentation

External Documentation

16

Internal Documentation Intended for a programmer-type

reader File header comments Component (e.g., objects, functions)

header comments Component body comments Local data documentation Meaningful variable names Formatting

17

External Documentation Intended for non-programmer-types

(maybe those who never read code) Describe the problem addressed by the

component; when invoked; why needed Describe the algorithms – rationale,

formulas, boundaries, special conditions Describe the data – component level

data flow