cmsc 345 programming. organization of coding process select “core” to implement first, following...
TRANSCRIPT
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”
www.desys.de/user/projects/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 attemptint FindPeriod (char *s){ int j = 0, found = 0;
while (!found && j < 80){
found = (s[j] == ‘.’);j++;
}return (found ? j : -1);
}
Generalized Versionint 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