Administrative issues

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 (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? (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 (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 (c) Ian Davis

5. (c) Ian Davis

6. (c) Ian Davis

7. (c) Ian Davis

8. (c) Ian Davis

9. (c) Ian Davis

10. (c) Ian Davis

11. (c) Ian Davis

12. (c) Ian Davis

13. (c) Ian Davis

14. (c) Ian Davis

15. (c) Ian Davis

16. (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 (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. (c) Ian Davis

19. (c) Ian Davis

20. (c) Ian Davis

21. (c) Ian Davis

22. (c) Ian Davis

23. Low level utilities • Wrap malloc/realloc/free • 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 (c) Ian Davis

24. void log(const char *fmtP, ...) { va_listarg; va_start(arg, fmtP); vfprintf(stderr, fmtP, arg); va_end(arg); fflush(stderr); if (g_logF) { va_start(arg, fmtP); vfprintf(g_logF, fmtP, arg); va_end(arg); fflush(g_logF); } } (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 (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. (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. (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 (c) Ian Davis

29. (c) Ian Davis

30. (c) Ian Davis

31. (c) Ian Davis

32. (c) Ian Davis

33. (c) Ian Davis

34. (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. (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. (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. (c) Ian Davis

38. Coupling criteria • Size of interface • 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 (c) Ian Davis

39. Coupling criteria • Visibility • 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 (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. (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 • All data passed as parameters/return result • Most/all of structures passed relevant • Weak data-structure coupling (WEAK) • Little information in structures passed relevant (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 (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. (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. (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. (c) Ian Davis