CMSC 345 Programming

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)

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

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

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

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

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

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

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)

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

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

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.

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

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

Donald Knuth “Why I Must Write Readable Programs” /LitProg/Philosophy.html

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

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

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

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); }

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

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

Documentation Constituency Problem Internal Documentation External Documentation

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

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