The Nitty and the Gritty

1. The Nitty and the Gritty CS130 Lecture 7 CS130 Prof Majumdar Lecture 7

2. Where we Are Started with requirements Progressively digging deeper Specifications: What to build Design: How to build Architecture: Detailed plan for the design Design Patterns: More detailed plans Today: Code level details A VERY brief survey from McConnell�s Code Complete CS130 Prof Majumdar Lecture 7

3. Where will we go Next? Next few lectures will be on testing/debugging Current practice as well as current research in testing/software quality One of the most exciting directions in software engineering research! CS130 Prof Majumdar Lecture 7

4. Code Level Decisions Programming Language Programming Conventions Not required by language, but often crucial Examples: �All executables will have �version option� Variable naming conventions Programming Tools and Frameworks Example: IDEs (Eclipse), debug tools, Frameworks: J2EE, .NET, Spring, Ruby on Rails � CS130 Prof Majumdar Lecture 7

5. Designing Your Software Key Challenge: Manage Complexity �Essential Problems� (underlying problem is hard or ill-defined) vs �Accidental Problems� (language does not have particular features) Goal: Modularize essential complexity How? Stratification (abstract layers) Loose coupling Extensibility and reusability Portability No formula: heuristic process CS130 Prof Majumdar Lecture 7

6. Design Heuristics Find a real-world analogy for objects Encapsulate details, hide information Makes programs easier to modify Pattern example? Isolate areas likely to change Pattern example? CS130 Prof Majumdar Lecture 7

7. Working Classes Class = Cohesive collection of data and routines that share a responsibility And let you ignore the rest of the program when looking at class implementation Ignore class implementation when looking at use Based on Abstract Data Types Hide implementation details, localize effect of changes CS130 Prof Majumdar Lecture 7

8. Good Abstractions Consistent level of abstraction Eg don�t mix several responsibilities Understand the abstraction from the problem viewpoint Enforce interfaces Limit accessibility to methods/members Don�t let client depend on assumptions beyond interface Eg: hash table client should not assume ordering of values CS130 Prof Majumdar Lecture 7

9. Routines Aka methods, functions, subroutines Routines reduce complexity Introduce understandable abstraction Avoid duplicate code Simple routines are good Don�t be shy of writing small ones CS130 Prof Majumdar Lecture 7

10. Routine Cohesion How closely its operations are related Functional cohesion (best) Routine does one thing only Sequential cohesion Operations share data and must be done in sequence Bad design: Procedural cohesion Routine exists only to sequence operations Coincidental cohesion = no cohesion CS130 Prof Majumdar Lecture 7

11. Naming Conventions [short digression: Naming conventions in McConnell�s book is spread over several sections [7.3: routines, 10: variables, 12.7: constants, 12.9: types]. I don�t like that.] No universal naming convention But projects need naming conventions To let you concentrate on more important things Compensate for some language weaknesses Emphasize relationships otherwise missed CS130 Prof Majumdar Lecture 7

12. Typical Naming Conventions Routines: verb (OO languages) or verbObject (non-OO) Opposites used precisely: min/max, open/close Give Boolean variables logical names: Status_ok or Status_not_found (rather than status, or status_error) Many more conventions, project specific conventions CS130 Prof Majumdar Lecture 7

13. Possible Things to Identify viaNaming Conventions Types vs Variables vs Constants Ex: Constants in ALL_CAPS i,j integer indices, p pointer, s string Globals vs Locals vs Members Inputs, Outputs, InputOutputs CS130 Prof Majumdar Lecture 7

14. Naming Conventions Example General Advice: Name should accurately describe the named entity E.g.: bpp ? bytes_per_page Names should be specific E.g.: do_work ? compute_bytes_per_page Names should relate to problem, not solution E.g.: two_to_the_bits ? bytes_per_page Names should have �right� length Typically, <= 20 chars, small scope names can be small (i, x), Others larger CS130 Prof Majumdar Lecture 7

15. Naming Conventions: More bytesPerPage vs bytes_per_page Surprising how much time is lost! Consistency is important!! Bottom Line: Favor read-time convenience over write-time convenience CS130 Prof Majumdar Lecture 7

16. Bad Names Visual puns: si10 vs silo Inside jokes: revenge_on_joe �similar sounding�: cownt, count Similar names, different work: aBufLength, a BufferLength Similar work, different names: inputLength, il CS130 Prof Majumdar Lecture 7

17. Defensive Programming Write code so that bugs are easier to catch and fix Not a substitute for good design principles! Basic Idea: Don�t trust the external world CS130 Prof Majumdar Lecture 7

18. Example: What�s Wrong? int a(int arr[], int n, int i) { return a[i]; } int a(int arr[], int n, int i) { assert(0<= i && i < n); return a[i]; } CS130 Prof Majumdar Lecture 7

19. What�s Wrong? x = (struct foo *)malloc(); � x->a = 0; CS130 Prof Majumdar Lecture 7 Better: x = (struct foo *)malloc(); If(x == NULL) { � handle error � } � x->a = 0;

20. What�s Wrong? s = inputString(); Printf(s); What if s has format characters? e.g: S = �%n�? Look up %n ? CS130 Prof Majumdar Lecture 7

21. What�s Wrong? S = �SELECT pwd FROM Table WHERE name = �; Name = inputString(); Query = S ^ Name; Execute(Query); SQL Injection Attack: What if Name is �Foo� || 1 == 1 Or �Foo� ; DELETE Table Similar issues in cross site scripting CS130 Prof Majumdar Lecture 7

22. What�s Wrong? Lock(); � If(error condition) { � return; } Unlock(); Return; On error condition, lock is not released Lead to deadlock CS130 Prof Majumdar Lecture 7

23. What can you do? Input Validation Taint analysis: make sure input data always passes through validator Assertions Contracts (pre- and post-conditions) Static Analysis CS130 Prof Majumdar Lecture 7

24. Refactoring Myth: Coding can proceed linearly, ie written once, tested, and forgotten. Reality: Various �upstream� issues change, code evolves substantially during initial development CS130 Prof Majumdar Lecture 7

25. Refactoring Change internal structure, not observable behavior, in order to make code easier to understand and modify Motivated by projects that evolve during construction Agile/XP development CS130 Prof Majumdar Lecture 7

26. When to Refactor? Duplicate Code Unused code Awkward API Poorly encapsulated classes �God� class Class that does little Routines grouped together that shouldn�t be Too long routine, too many parameters Often called �smells� [Martin Fowler] CS130 Prof Majumdar Lecture 7

27. Refactoring Techniques General �principles� DRY: Don�t repeat yourself (Copy and paste is a design error) Do refactorings one at a time Be prepared to undo Keep refactorings small Organize TEST CS130 Prof Majumdar Lecture 7

28. Techniques Replace code with routine Encapsulate data (eg introduce class) Rework routine to avoid duplication Change values to references and vice versa Pull a routine up to superclass Push a routine to subclass Move routine from interface Add inheritance/delegation Centralize access to data CS130 Prof Majumdar Lecture 7

29. Refactor Gradually �As you go� rather than �all at once� CS130 Prof Majumdar Lecture 7

30. Code Tuning Performance often conflicts with other design goals Example of design pattern that can reduce performance? Many patterns introduce indirection Factories, Strategies, � Indirection is costly CS130 Prof Majumdar Lecture 7

31. Code Tuning Question to ask: Are you sure you want to sacrifice design for performance? Answer is �no� most of the time Other things you can do: Change platform (HW, OS, language) Algorithmic improvements 80-20 rule (80% of execution in 20% of code) Amdahl�s Law CS130 Prof Majumdar Lecture 7

32. Why Not to Optimize Is it really a bottleneck? Programmer intuitions often poor You can waste work unnecessarily optimizing code Best to optimize later, when bottlenecks can be identified better (ideally, through profiling) Ideal flow: Iterate: Measure to find biggest bottlenecks Tune code to address it Measure result; discard if it didn�t help Repeat CS130 Prof Majumdar Lecture 7

33. Ok, You really want to Tune �Standard� tuning strategies Stop testing when you find the answer Order tests by frequency Substitute table lookups for complicated computations Put busiest loop on the inside Caching Loop unswitching, jamming, unrolling (these are often done well by compilers) Parallelize (for multicores) � but not easy As compilers get better, some advice gets obsolete CS130 Prof Majumdar Lecture 7

34. Internationalization and Localization I18n and L10n Adapt software to different languages and regional differences Why? Want access to different regional markets without major changes in code How do you design software so that you can convert all messages, time/date formats, etc from one language/region to another? Example: Date format: US MM/DD/YY, Europe: DD/MM/YY CS130 Prof Majumdar Lecture 7

35. I18n, L10n What to change: Alphabets/scripts: Most systems use Unicode standard to resolve character encoding issues Language translation: Normal and error messages, menu titles, � Currency, weights and measures, ID numbers, telephone numbers, � Number formats (decimal point vs comma, positioning) CS130 Prof Majumdar Lecture 7

36. What�s Done? Place text in resource strings which are loaded during program execution as needed Resource strings translated into various languages No code change required, only point to a different �locale� to load appropriate strings See e.g. GNU gettext Difficulties: Have to keep parallel versions of the strings consistent through project lifetime Some other details (direction of writing) not so easy, and may be solved using compilation time switches CS130 Prof Majumdar Lecture 7

37. More Info IBM globalization (g11n) web site: http://www-01.ibm.com/software/globalization/index.jsp Microsoft globalization website http://msdn.microsoft.com/en-us/goglobal/bb688110.aspx Java: http://java.sun.com/developer/technicalArticles/Intl/IntlIntro/ CS130 Prof Majumdar Lecture 7

38. Administrative Items Project 3 (design review) due Monday HW 2 is up (due Wednesday) Tell me what each group is up to? CS130 Prof Majumdar Lecture 7