*   NOTE:
    *   you have a Homework 7 handout, and that's due
        FRIDAY, November 11

    *   tomorrow's IN LAB presentations
        will BE part of HOMEWORK 8

        the other part of Homework 8?
	*   individual reflections - in 458hw8.txt
        *   your name will be there
	*   What is something you think went well in your
	    team's presentation?
        *   What is something you learned from another
	    team's presentation?
        *   What is something you'd like to improve on/	
            do better in your next team presentation?
	*   compare THIS presentation's requirements
	    (as posted in the Week 11 Lab projections)
	    to the FINAL presentation's requirements
	    (as given in the Project handout) --
	    give at least 3 DIFFERENCES between
	    THIS presentation's requirements and
	    the FINAL presentation's requirements

*   Jalote Ch. 7 - CODING and UNIT TESTING --
    
*   ...jumping around in terms of in-class coverage!
    (but you should still read all of it...)

*   Weinberg's experiment
    *   5 different teams of programmers
    *   each given the SAME problem to solve
    *   but each specified a different objective:
        *   minimize effort to complete
	*   minimize number of statements
        *   minimize memory required
        *   maximize program clarity
        *   maximize output clarity

    *   in MOST cases, the team did BEST (of the 5) for
        the objective specified to it;

        ^   SUGGESTS that, IF objectives are clear,
	    programmers TEND to achieve them;

	    ^   do managers give objectives that
	        really reflect what is wanted?

    *   chart on p 182 also showed that for the team
        focusing on minimizing coding effort,
	their program clarity did NOT rank well;

	(and seeking to maximize output clarity
	seemed to have good effects on program clarity...)

*   Chapter 7 - HAVE your high-level design,
    modules with low coupling and high cohesion!

    ..and now you want to implement the design in the
    best possible manner!

    *   coding, testing, and maintenance really ARE
        interrelated --

	how can coding and unit test be done to
	EASE maintenance later?

    *   another important idea:
        Code is read a lot more, and by more people,
	that just by its writer when it is written;

        ...code should be written so it is easy
	to understand and read, not easy to write;

*   structured programming
    *   movement that started in th 1970s --
        Dijkstra's famous letter, "GOTO considered harmful"

        *   dynamic structure (sequence of statements executed)
	    should resemble its static structure 
	    (structure of the text of the statements)

        *   ...because it makes the code easier
	    to understand;

	*   argues for using the basic structures
	    (e.g., branching, sequence, repetition,
	    procedure) rather than use of GOTO

        *   argued for single-entry, single-exit
	    structured statements

        *   (original motivation: to help with formal
	    verification of programs

	    Hoare's notation:

	    P{S}Q

	    P - assertion P, precondition
            Q - assertion Q, postcondition
            S - statement or statements

	    P{S}Q - if P is true BEFORE executing S,
	            then Q will be true AFTER executing S

		    ^ program verification seeks to prove
		      this;

*   information hiding
*   programming practices
*   coding standards

*   "bad smells"
    *   things you notice in working/passing-unit-test code
        that suggest refactoring may be desired;
   
    *   in GENERAL, these MAY be indicative of poor design;
       
    *   note the MANY in the chapter...

*   code inspection
    *   another technique often used at the unit-code
        level
    *   main goal: detect DEFECTS in work products
    *   recognized as an industry best practice

    *   conducted by group of programmers FOR programmers
        (review done by PEERS)

        *   (officially? typically? the best-practice version?)
	    is a STRUCTURED process with DEFINED
	    roles for the participants

        *   focus is on identifying and logging problems,
	    not resolving them then and there

	    ^ review data is RECORDED, logged, 
	      and that data can be used monitoring the
	      effectiveness of the review

    *   three-to-five people considered ideal for a code
        inspection team;
	*   moderator, reviewer, scribe

        *   members may review in advance;
	*   also a GROUP meeting,
	    *   reviewer goes over the code line by line
            *   at ANY line, all issues are raised (that
	        group members have)
            *   moderator is trying to maintain order,
	        amicability (?), progress

            *   scribe logs all the defects noted

        *   rework and follow-up phase afterwards;