1. Administrative issues
Questions about last lecture
All students members of a team
New waitlisted course arrivals
Contacting each other
Access to Piazza
Access to CS446 drop boxes on learn
No midterm
2017 Spring
(c) Ian Davis

2. Guest Lecture on Monday 15th
Jade Choy (and/or associates)
EPOCH
Are you aware of who EPOCH is??
I meet with Jade this afternoon
Any questions or issues of particular interest to you?
2017 Spring
(c) Ian Davis

3. Final comment about NFRs
Modern computers are fast
Can certainly have performance as a NFR
Occasionally (e.g. Liquid) performance kills you
Must be considered from the outset
Will be the elephant in the room dwarfing all else
But generally is better to actually worry about performance only if it becomes a proven issue
Don’t waste months fighting performance issues that are not even there – keep it simple safer option
2017 Spring
(c) Ian Davis

4. Another recommendation
Modern computers have lots of RAM
More can be added..
Liquid was running on a machine with 1TB of ram!!
I do not recommend compromising your data structures to squeeze more into them without real evidence this is absolutely necessary
LSEDIT (8 bytes per node, caching of duplicate values, concise path representation …)
CLANG AST
2017 Spring
(c) Ian Davis

5. 2017 Spring
(c) Ian Davis

6. 2017 Spring
(c) Ian Davis

7. 2017 Spring
(c) Ian Davis

8. 2017 Spring
(c) Ian Davis

9. 2017 Spring
(c) Ian Davis

10. 2017 Spring
(c) Ian Davis

11. 2017 Spring
(c) Ian Davis

12. 2017 Spring
(c) Ian Davis

13. 2017 Spring
(c) Ian Davis

14. 2017 Spring
(c) Ian Davis

15. 2017 Spring
(c) Ian Davis

16. 2017 Spring
(c) Ian Davis

17. Recommended strategies
Keep getting it wrong till you get it right
Plan to throw one away, you will anyway
If you plan to throw one away, you will throw two away
Throw bad ideas away early
Keep it simple stupid (KISS principle)
Enforce an architecture on everything
Plan for the long term
Generalize / encapsulate
2017 Spring
(c) Ian Davis

18. More recommendations Do things in the logical order
1. Registration / people profiles / login
2. Capture data / view data
3. Extend functionality
4. Permissions
Use a collaborative wiki for documenting:
Code / Design / Architecture
Meetings / Decisions etc.
2017 Spring
(c) Ian Davis

19. 2017 Spring
(c) Ian Davis

20. 2017 Spring
(c) Ian Davis

21. 2017 Spring
(c) Ian Davis

22. 2017 Spring
(c) Ian Davis

23. Low level utilities Wrap malloc/realloc/free Have single exit routine
Catch memory leaks
Have single exit routine
So can break point on exit
Have single abort routine
Permits final cleanup and trapping
Use a trap routine() for debugging
Make the code work for you
Write a log routine
2017 Spring
(c) Ian Davis

24. void log(const char. fmtP,
void log(const char *fmtP, ...) { va_listarg; va_start(arg, fmtP); vfprintf(stderr, fmtP, arg); va_end(arg); fflush(stderr); if (g_logF) { vfprintf(g_logF, fmtP, arg); fflush(g_logF); } }
2017 Spring
(c) Ian Davis

25. Defensive programming tips
Use lots of assertions.
Avoid creating assertions with side-effects.
Check correctness of inputs.
Anticipate unexpected types in case statements, etc.
Document changes and use version control
Monitor memory leakage
Implement interfaces as interfaces
Check for error returns
2017 Spring
(c) Ian Davis

26. Defensive programming tips
Use macros to support / facilitate change.
Nest macros using brackets.
Order parameters as input, update, output.
Use same parameter order for similar tasks.
Compare with fprintf() and fputs()
Use all parameters; optionally default some.
Don’t use parameters as working variables.
Hard to debug when viewing stack.
2017 Spring
(c) Ian Davis

27. Defensive programming tips
Prefix global and object state variables
eg. m_pointer, g_counter
Designate data private when appropriate.
Distinguish pointers from non-pointers.
Identify levels of indirection to arrive at an element using a pointer.
Use comments to explain what is clear as well as what is unclear.
2017 Spring
(c) Ian Davis

28. Orthogonal issues Detect and eliminate memory leakage's
Code should be re-entrant
Don’t condition logic based on static data
Code should be thread safe
Avoid global state
Protect object state against concurrent update
Code interrupt safe
Anticipate unexpected throws, interrupts etc.
Eg. out of memory or Cntl-C
2017 Spring
(c) Ian Davis

29. 2017 Spring
(c) Ian Davis

30. 2017 Spring
(c) Ian Davis

31. 2017 Spring
(c) Ian Davis

32. 2017 Spring
(c) Ian Davis

33. 2017 Spring
(c) Ian Davis

34. 2017 Spring
(c) Ian Davis

35. Cohesion Relationship of code within a routine.
How “strong” are the relationships.
Routines should do a single thing and do it well.
Goal: Create routines with internal integrity
50% of highly cohesive routines fault free.
18% of low cohesion routines fault free.
2017 Spring
(c) Ian Davis

36. Coupling
The “usefulness” and “effectiveness” of the connection between routines.
Compliment of cohesion.
Want small, direct, meaningful, visible, flexible relations.
Want “loose” coupling.
2017 Spring
(c) Ian Davis

37. Coupling Routines should not depend on their caller.
They should be detached and self contained.
They should be sufficiently general.
Routines should not share global data.
Routines should fulfill a purpose rather than be viewed as performing specific actions.
2017 Spring
(c) Ian Davis

38. Coupling criteria Size of interface Intimacy
Lots of complex parameters are bad
Lots of reference to global data bad
Intimacy
Immediacy of method of communication
Parameter and return result (GOOD)
Via messages (WEAKER)
Global data (DUBIOUS)
Via mediator/database etc (WEAK)
e.g. Dummy records written to tape
2017 Spring
(c) Ian Davis

39. Coupling criteria Visibility Flexibility Clarity
How are results manifest
By parameter (GOOD)
By side effect (BAD)
Flexibility
How easy is it to pass the right parameters
Is routine plug and play or overly specific
Clarity
Routines should have sensible names
2017 Spring
(c) Ian Davis

40. Coupling criteria
Routines should be able to call other routines easily.
The consequences of such calls should be both clear and straightforward.
Break up a program along lines of minimal interconnectedness.
Split with the grain; not against the grain.
2017 Spring
(c) Ian Davis

41. Levels of coupling Simple-data coupling (SIMPLEST/BEST)
Only non-structured data shared
All data passed as parameters/return result
Strong data-structure coupling (OK)
Structured data passed between routines
Most/all of structures passed relevant
Weak data-structure coupling (WEAK)
Little information in structures passed relevant
2017 Spring
(c) Ian Davis

42. Levels of coupling Control coupling (POOR)
Parameters tell called routine how to behave
Caller understands internal workings of callee
Global data coupled (HORRIBLE)
Two routines operate on same global data
Connection neither intimate nor visible
Pathologically coupled (DISASTER)
One routine directly uses another routines code
One routine directly alters another routines data
2017 Spring
(c) Ian Davis

43. Additional coupling consideration
Identify all constant parameters.
Use constant pointers whenever the structure pointed at will not be changed.
Consider in-lining very short routines.
Use generic names rather than return codes.
Use objects to encapsulate functionality.
Access objects via complete interfaces.
Use compilers which do full type checking.
2017 Spring
(c) Ian Davis

44. Size of a routine Routine size inversely correlated with error
As size  to 200 lines errors per line  (Basili)
Routine size not correlated with errors
Structural complexity and amount of data far more significant than routine size (Shen)
Larger routines (65+ lines) cheaper and no less reliable (Card)
Small routines (<143lines) has 23% more errors than larger routines.
2017 Spring
(c) Ian Davis

45. Size of a routine
Code in which all routines about 10 lines long, as incomprehensible as code without routines at all (Conte).
Code required less change when routines averaged 100 to 150 lines of code. (Lind).
Practical upper limit on routine size about 200 lines of hard code (without comments).
Most buggy routines had > 500 lines code.
2017 Spring
(c) Ian Davis