CMSC 345

1. CMSC 345 Programming

2. Organization of Coding Process • Select “core” to implement first, following an incremental development model • Reconsider architectural views and eliminate anything not critical • Reconsider object/operations models and eliminate all unnecessary for mandatory requirements and/or easy extension to desirable requirements • Micromanage your team but distribute/delegate responsibility (everyone should be in charge of something)

3. Select “Core” • Must be compileable, buildable, runable, demoable, deployable, usable and maintainable • Start over, try not to base on prototype • Brooks: plan to throw one away, you will anyway • But encourage customers/users to experiment with the prototype(s) and provide rapid feedback • Make sure all mandatory requirements will be satisfied and all desirable requirements are easy to add • Possibly reprioritize functional and nonfunctional requirements in consultation with customer

4. Work Breakdown • Baseline process/component/object/operation interfaces before coding • One team member should be in charge of configuration management and change control wrt interfaces, no changes w/o his/her approval • One team member should be in charge of code checkin/checkout and file directory structure • One team member should be in charge of integration planning, assuming those interfaces and source code file directory structure • One team member should be in charge of tracking that everyone is doing what they’re supposed to do on schedule, should be in daily contact with all team members

5. Coding Style • Each team should jointly choose a coding/commenting style and enforce it • 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

6. Team Programming Issues • Agree in advance on identifier naming, indentation, and commenting conventions • Think in terms of how “diff” will react to code modifications if you diddle the formatting • Maintain development history in prologue of each file - owner, date of creation, dates of all updates and brief description of each update • Any changes made by “non-owner” anywhere in file preceded by comment indicating name - plus update history in prologue

7. “Defensive Programming” • 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 • Build fault tolerance into complex data structures (e.g., back references in linked structures)

8. 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 prompt and accept blank input to refer to default • When there is a choice among a small number of simple values, list all of them in prompt

9. Label All User Outputs • Clearly explain all user output along with the output • Provide options for at least two levels of verbose and terse output modes (also applicable to prompts) • Probably also testing mode (for use by testing drivers or scripts) • If the user has to “wait”, give 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)

10. Program Standards • Everybody’s got them • Help you organize thoughts and avoid mistakes • Lets you focus on the problem • Must organize, format and document your code to make it easy for others to understand

11. The Problem • In some companies that write computer software, about 10% of the hours spent of software development is spent writing and 90% is spent doing maintaining, debugging, and documenting the code. • 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).

12. Problems (2) • 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). • It is often more difficult to reuse software someone else has written then to rewrite it your self because it is hard to figure-out how it works.

13. Problems (3) • 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).

14. Why the problem? • Programming languages are designed more for encouraging people to write code for a compiler to understand than for other people to understand • Especially C

15. Donald Knuth • “Why I Must Write Readable Programs” • www.desys.de/user/projects /LitProg/Philosophy.html

16. Structured Programming • Regardless of programming language, each program component involves at least • Control structures • Algorithms • Data Structures

17. Control Structure Example • Write a C function that searches an80-character string for the first occurrence of a period and returns the index where found, or –1 if not found

18. First attempt int FindPeriod (char *s) { int j = 0, found = 0; while (!found && j < 80) { found = (s[j] == ‘.’); j++;} return (found ? j : -1); }

19. Generalized Version int FindChar (char *s, char c) { int j = 0, found = 0; while (!found && s[j]) { found = (s[j] == c); j++;} return (found ? j : -1); }

20. Algorithms • Fast code is overrated and has cost • Cost to write the faster code – more complex and takes more time • Cost of time to test complex code • Cost of time for users to understand code • Cost of time to modify the code • Execution time is only a small part of cost equation. Balance execution time with design, quality and customer requirements • DO NOT sacrifice CLARITY and CORRECTNESS for speed

21. Data Structures • Tax example -- Keep Program Simple • First $10000, tax is 10% • Next $10000 above $10K, tax is 12% • Next $10000 above $20K, tax is 15% • Next $10000 above $30K, tax is 18% • Any income above $40K, tax is 20% • Use tax table for loop, not if-else

22. Documentation • Constituency Problem • Internal Documentation • External Documentation

23. Internal Documentation • Header Block Comments • Other Program comments • Meaningful Variable names • Formatting to enhance understanding • Typography and layout • Documenting data • Data dictionary

24. External Documentation • Read by those who never read the code • Describe the problem addressed by the component; when invoked; why needed • Describe the algorithms – rationale, formulas, boundary, special conditions • Describe the data – component level data flow