COMP1730/COMP6730 Programming for Scientists
Code Quality & Debugging
Announcements
* Marks for Homework 1 available on Wattle. If you think there is a mistake, pls first talk with your Tutor in the lab this week! We will then discuss with the Tutors to clarify the case. Do not change the testing function!
* Mid-semester exam: Monday, week 7 (16th Sep).
* Please fill out questionnaire about conflicts with other exams in weeks 6 and 7 until Fri 23rd Aug, 6pm.
Lecture outline
* What is “code quality”? * Testing & debugging
* Defensive programming
Code quality
What is code quality and why
should we care?
* Writing code is easy – writing code so that you (and others) can be confident that it is correct is not.
* You will always spend more time finding and fixing the errors that you made (“bugs”) than writing code in the first place.
* Good code is not only correct, but helps people (including yourself) understand what it does and why it is correct.
(Extreme) example
* What does this function do? Is it correct?
def AbC(ABc):
ABC = len(ABc)
ABc = ABc[ABC−1:−ABC−1:−1] if ABC == 0:
return 0
abC = AbC(ABc[−ABC:ABC−1:]) if ABc[−ABC] < 0:abC += ABc[len(ABc)−ABC] return abC(Extreme) example – continued* What does this function do? Is it correct?def sum negative(input list): ’’’Sums up all the negative numbers in input list.’’’ total = 0for number in input list: if number < 0:total = total + number return totalAspects of code quality* Commenting and documentation. * Variable and function naming.* Code organisation.* Code efficiency (somewhat).What makes a good comment?* Raises the level of abstraction: what the code does and why, not how.- Except when “how” is especially complex.* Describe parameters and assumptions– python is not a typed language.* Up-to-date and in a relevant place.* Don’t use comments to make up for poor qualityin other aspects (organisation, naming, etc.).* Good commenting is more important whenlearning to program and when working with other people.Function docstring* A (triple-quoted) string as the first statement inside a function (module, class) definition.* State the purpose and limitations of the function, parameters and return value.def solve(f, y, lower, upper):’’’Returns x such that f(x) = y.Assumes f is monotone and that a solution lies in the interval [lower, upper](and may recurse infinitely if not).’’’* Can be read by python’s help function. * Do not mix comments with docstring!What makes a bad comment?* Stating the obvious.x = 5 # Sets x to 5.* Used instead of good naming.x = 0 # Set the total to 0.* Out-of-date, separate from the code it describes, or flat out wrong.# loop over list to compute sum:avg = sum(the list) / len(the list)* More comments than code is (usually) a sign that your program needs to be reorganised.Good naming practice* The name of a function or variable should tell you what it does / is used for.* Variable names should not shadow a names of standard types, functions, or significant names in an outer scope.def a fun fun(int):a fun fun = 2 ∗ intmax = max(a fun fun, int) return max < int(more about scopes in a coming lecture).* Names can be long (within reason).- A good IDE will autocomplete them for you.* Short names are not always bad:- i (j, k) are often used for loop indices.- n (m, k) are often used for counts.- x, y and z are often used for coordinates.* Don’t use names that are confusingly similar in the same context.- E.g., sum of negative numbers vs.sum of all negative numbers – what’s the difference? Code organisation* Good code organisation- avoids repetition;- fights complexity by isolating subproblems andencapsulating their solutions;- raises the level of abstraction; and- helps you find what you’re looking for.* python constructs that support good code organisation are functions, classes (not covered in this course) and modules (later).getDressed() run() shower() getDressed() lift() shower()def doFitnessActivity(activity): getDressed()activity()shower() doFitnessActivity(run) doFitnessActivity(lift) Functions* Functions promote abstraction, i.e. they separate what from how.* A good function (usually) does one thing. * Functions reduce code repetition.- Helps isolate errors (bugs).- Makes code easier to maintain.* A function should be as general as it can be without making it more complex.def solve(lower, upper):’’’Returns x such thatx ∗∗ 2 ∗ pi ~= 1. Assumes …’’’vs.def solve(f, y, lower, upper): ’’’Returns x such that f(x) ~= y. Assumes …’’’EfficiencyPremature optimisation is the root of all evil in programming.C.A.R. Hoare* Modern computers usually have enough power to solve your problem, even if the code is not perfectly efficient.* Programmer time is far more expensive than computer time.* Code correctness, readability and clarity is more important than optimisation.When should you consider efficiency?* For code that is going to run very frequently.* If your program is too slow to run at all.A poor choice of algorithm or data structure may prevent your program from finishing, even on small inputs.* When the efficient solution is just as simple and readable as the inefficient one.Testing & DebuggingUnit testing* Different kinds of testing (load, integration, user experience, etc) have different purposes.* Testing for errors (bugs) in a single program component – typically a function – is called unit testing.- Specify the assumptions.- Identify test cases (arguments), particularly“edge cases”.- Verify behaviour or return value in each case.* The purpose of unit testing is to detect bugs.Good test cases* Satisfy the assumptions.* Simple (enough that correctness of the valuecan be determined “by hand”).* Cover the space of inputs and outputs.* Cover branches in the code.* What are edge cases?- Integers: 0, 1, -1, 2, …- float: very small (1e-308) or big (1e308) – Sequences: empty (’’, []), length one.- Any value that requires special treatment inthe code.What is a “bug”?We could, for instance, begin with cleaning up our language by no longer calling a bug a bug but by calling it an error. It is much more hon- est because it squarely puts the blame where it belongs, viz. with the programmer who made the error. The animistic metaphor of the bug that maliciously sneaked in while the program- mer was not looking is intellectually dishonest as it disguises that the error is the program- mer’s own creation.E. W. Dijkstra, 1988The debugging process1. Detection – realising that you have a bug.2. Isolation – narrowing down where and when it manifests.3. Comprehension – understanding what you did wrong.4. Correction; and5. Prevention – making sure that by correcting theerror, you do not introduce another.6. Go back to step 1.Kinds of errors* Syntax errors.- IDE/interpreter will tell you where they are.* Runtime errors – code is syntactically valid, but you’re asking the python interpreter to do something impossible.- E.g., apply operation to values of wrong type, call a function that is not defined, etc.- Causes an exception, which interrupts the program and prints an error message.- Learn to read (and understand) python’s error messages!# SyntaxError: invalid syntaxif spam = 42: print(’Hello!’)# IndentationError: unexpected indentprint(’Hello!’) print(’Howdy!’)# TypeError: ’str’ object does not support item # assignmentspam = ’I have a pet cat.’spam[13] = ’r’# IndexError: list index out of rangespam = [’cat’, ’dog’, ’mouse’] print(spam[6])* Semantic errors (logic errors).- The code is syntactically valid and runswithout error, but it does the wrong thing(perhaps only sometimes).- To detect this type of bug, you must have agood understanding of what the code issupposed to do.- Logic errors are usually the hardest to detectand to correct, particularly if they only occur under certain conditions.* python allows you to do many things that you never should.Isolating and understanding a fault* Work back from where it is detected(e.g., the line number in an error message).* Find the simplest input that triggers the error.* Use print statements (or debugger) to seeintermediate values of variables andexpressions.* Test functions used by the failing programseparately to rule them out as the source of theerror.- If the bug only occurs in certain cases, theseneed to be covered by the test set.Some common errors* python is not English.if n is not int: …if n is (not int): …* Statement in/not in suite.while i <= n:s = s + i∗∗2i=i+1 return s* Precision and range of floating point numbers.* Loop condition not modified in loop.def solve(f, y, lower, upper):mid = (lower + upper) / 2while math.fabs(f(mid) − y) > 1e−6:
if f(mid) < y: lower = midelse:upper = midreturn midDefensive programmingEveryone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?Brian Kernighan* Write code that is easy to read and well documented.- If it’s hard to understand, it’s harder to debug.* Make your assumptions explicit, and fail fast when they are violated.Assertionsassert test expressionassert test expression , “error message”* The assert statement causes a runtime error if test expression evaluates to False.* Violated assumption/restriction results in an immediate error, in the place where it occurred.* Don’t use assertions for conditions that will result in a runtime error anyway (typically, type errors).# Bad practice (delayed error)defsum of squares(n): if n < 0:return “error: n is negative” return (n ∗ (n + 1) ∗ (2 ∗ n + 1)) // 6 ……sum of squares(m)sum of squares(m − k)sum of squares(k)m =k =a =b =c =if a − b != c: print(a, b, c)# Good practice (immediate error)defsum of squares(n):assert n >= 0, str(n) + ” is negative” return (n ∗ (n + 1) ∗ (2 ∗ n + 1)) // 6 …
…
sum of squares(m)
sum of squares(m − k)
sum of squares(k)
m =
k =
a =
b =
c =
if a − b != c:
print(a, b, c)
* Write explicit code, even when python implicitly does the same thing.
def find box(color): pos = 0
while robot.sense color() != ’’:
if robot.sense color() == color:
return pos robot.lift up()
pos = pos + 1
return None # color not found
vs.
def find box(color): pos = 0
while robot.sense color():
if robot.sense color() == color:
return pos robot.lift up()
pos = pos + 1
* Don’t use “language tricks” when they obscure the meaning.
Reviews
There are no reviews yet.