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