CMSC 345

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 (cont)

• One team member charge of tracking that everyone
  is doing what theyre 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

• Everybodys 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 (cont)

• 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 (its
  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