The Nitty and the Gritty
CS130 Lecture 7
CS130 Prof Majumdar Lecture 7
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 McConnells Code
Complete
CS130 Prof Majumdar Lecture 7
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
Code Level Decisions
1. Programming Language
2. Programming Conventions
Not required by language, but often crucial
Examples: All executables will have version
option
Variable naming conventions
3. Programming Tools and Frameworks
Example: IDEs (Eclipse), debug tools,
Frameworks: J2EE, .NET, Spring, Ruby on Rails
CS130 Prof Majumdar Lecture 7
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
Design Patterns
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
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
Good Abstractions
Consistent level of abstraction
Eg dont mix several responsibilities
Understand the abstraction from the problem
viewpoint
Enforce interfaces
Limit accessibility to methods/members
Dont let client depend on assumptions
beyond interface
Eg: hash table client should not assume ordering
of values
CS130 Prof Majumdar Lecture 7
Routines
Aka methods, functions, subroutines
Routines reduce complexity
Introduce understandable abstraction
Avoid duplicate code
Simple routines are good
Dont be shy of writing small ones
CS130 Prof Majumdar Lecture 7
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
Naming Conventions
[short digression: Naming conventions in McConnells book is
spread over several sections [7.3: routines, 10: variables, 12.7:
constants, 12.9: types]. I dont 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
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
Possible Things to Identify via
Naming 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
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
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
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
Defensive Programming
Write code so that bugs are easier to
catch and fix
Not a substitute for good design
principles!
Basic Idea: Dont trust the external
world
CS130 Prof Majumdar Lecture 7
Example: Whats 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
Whats Wrong?
x = (struct foo
*)malloc();
x->a = 0;
Better:
x = (struct foo
*)malloc();
If(x == NULL) {
handle error
}
x->a = 0;
CS130 Prof Majumdar Lecture 7
Whats Wrong?
s = inputString();
Printf(s);
What if s has format
characters?
e.g:
S = %n?
Look up %n
CS130 Prof Majumdar Lecture 7
Whats 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
Whats Wrong?
Lock();
If(error condition) {
return;
}
Unlock();
Return;
On error condition,
lock is not released
Lead to deadlock
CS130 Prof Majumdar Lecture 7
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
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
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
When to Refactor?
Duplicate Code
Unused code
Awkward API
Poorly encapsulated classes
God class
Class that does little
Routines grouped together that
shouldnt be
Too long routine, too many parameters
Often called smells [Martin Fowler]
CS130 Prof Majumdar Lecture 7
Refactoring Techniques
General principles
DRY: Dont 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
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
Refactor Gradually
As you go rather than all at once
CS130 Prof Majumdar Lecture 7
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
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)
Amdahls Law
CS130 Prof Majumdar Lecture 7
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 didnt help
Repeat
CS130 Prof Majumdar Lecture 7
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
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
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
Whats 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
More Info
IBM globalization (g11n) web site:
http://www-01.ibm.com/software/globalization/in
dex.jsp
Microsoft globalization website
http://msdn.microsoft.com/en-us/goglobal/bb68
8110.aspx
Java:
http://java.sun.com/developer/technicalArticles/Intl/IntlIntro/
CS130 Prof Majumdar Lecture 7
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
