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 (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 originalauthor 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