CMSC 345 Programming. Organization of Coding Process Select “core” to implement first, following an incremental development model Reconsider architectural.

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