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