CMSC 345 Programming

Topics Work Breakdown Coding Standards Defensive Programming Structured Programming Documentation

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)

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

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

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).

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).

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

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)

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

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)

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

Control Structures Keep them as top-down as possible - no “spaghetti code” Are a good clue as to when a comment is needed

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

Documentation Internal Documentation External Documentation

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

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