CS242

Reduce Complexity Introduce an intermediate, understandable

abstraction Avoid code duplication Support subclassing Hide sequences Hide pointer operations Improve portability Simplify complicated boolean tests Improve performance Insure all routines are small?

Isolate complexity Hide implementation details Limit effects of changes Hide global data Make central points of control Facilitate reusable code Accomplish a specific refactoring

Each routine should do ONE thing and do it well

Results Higher reliability Easier debugging Easier maintainability Easier to understand

Describe everything the routine does Avoid meaningless, vague or wishy-washy verbs

Handle, process, output, “deal with” Don’t differentiate routine names solely by

number – OutputUser1 Make names of routines as long as necessary

(ok, be reasonable) To Name a function – describe return value

sin(), cos(), atan(), etc To Name a procedure – strong verb object

BuildNormalVectorTable(normaltable* normals, raster* r)

Should be impervious or immune to bad input (?)

Avoid catch-all routines Avoid HIDDEN side-effects Stick to a standard parameter ordering Limit the number of parameters Be mindful of the way data is passed to a

routine Avoid speculative generality

Solve today’s problem today

This is true when public Local, helper, private routines may

assume no bad input Use asserts during development

Catch-alls will have characteristics like flags that indicate operations to be performed

Dispatch to smaller, simpler functions if you can’t think of a cleaner design

Do not modify global data Do not

Clear memory Create anything Destroy anything Unless that is the purpose of the routine or it

is only for the duration of the routine

Stick to a standard parameter ordering Example:

Destination first Source next Flags last (any values that modify the destination or source

immediately follow destination or source Decreasing order of importance

CopyValue(destRaster, row, column, sourceRaster, row, column);MapValues(destRaster, WATER, SWAMP);

Limit the number of parameters to about 7

Be mindful of the way data is passed to a routine

Do not pass large structures or strings to be modified, pass a reference instead

Solve today’s problem today Be general only when you KNOW it will be useful

This is a potential time sink

No set rule, except in this class We set that arbitrarily at 25 lines

One screen of code: 50–150 lines Length IS correlated with errors Cost?

Order of parameters: Input Modify Output

Consider your own “in” and “out” keywords Use a consistent ordering scheme Use all the parameters Put status or error variables last Don’t use routine parameters as working variables

Create a local working variable instead Document interface assumptions about parameters Limit the number of a routine’s parameters to about seven Consider an input, modify, output naming convention for

parameters Pass the variables or objects that the routine needs to maintain

its interface Make sure actual parameters match formal parameters

Function vs Procedure Function returns only one value like sin()

Setting function return values Check all possible return paths Don’t return references or pointers to local

data

Fully parenthesize macro expressions Surround multiple-statement macros with

curly braces Name macros like routines so they can be

replaced with routines Limitations

Const Inline Template Enum Typedef

The documentation provided does not exactly match the data

But it is sufficient to complete the assignment

Write routines to accomplish the following in the BMP: Read a single value from the BMP Set a single value in the BMP Fill a row with a value Fill a column with a value Fill part of a row Fill part of a column Draw a line segment Fill a rectangle Fill a non-convex polygon

Polygon fill - http://alienryderflex.com/polygon_fill/

Bresenham’s line algorithm http://en.wikipedia.org/wiki/

Bresenham's_line_algorithm

Cases All four corners in bounds 2 corners in bounds 1 corner in bounds No corners in bounds