lecture 4: coding in groups
DESCRIPTION
Why should I learn about marketing ? I’m in CSC to avoid this!. MKT 101 – Introduction to Marketing. Lecture 4: Coding In Groups. Today’s Goal. Start moving from design to implementation How to catch and fix bugs while its easy to fix - PowerPoint PPT PresentationTRANSCRIPT
LECTURE 4:CODING IN GROUPS
MKT 101 – Introduction to Marketing
Why should I learn about
marketing?I’m in CSC to avoid
this!
Today’s Goal
Start moving from design to implementation How to catch and fix bugs while its easy to
fix Methods we can use to avoid writing
useless code How to test without JUnit or even writing
tests Important ways that projects started in real
world Documentation & testing are connected;
how?
Time Required To Understand
Atte
ntio
n Pa
idHow My Homies Roll
Reactions to Your Code
Time Spent
Use
r’s
Abili
ty
Passion Threshold
Suck Threshold
Making users think is preying on their weakness Explicitly state all details needed to use
code Users will assume that everything has a
purpose Male nipples & appendix continue to be
discussed If it does not serve purpose, why else create
it? Guessing game created from unused
parameters Don't make user probe what method return
means
Intuitive Is Key
What To Do With Your Design
Move on to next step: write your javadoc Verifies your design logical and could
actually work Makes developing code in larger teams
simple Enables developing tests before code is
written If done well, will actually suggests tests to
write
But We Cannot Document Yet!
Of course, do not yet know details such as… How method is coded or calls it makes Which of the class’s fields used within
method How it computes result to get return value Given an input, why specific algorithm used
javadoc does NOT need & should not include it You may (or should be asking yourself):
Why?
Why Not Include Details?
You write code once… This is goal, idea is to solve problems not
write code Writing code is work & laziness means
minimizing this Once code bug free, do not want to look at
it again …but read comments often
If javadoc duplicates code, could just read code
Only provide what users need
What Should Comments Say?
Design has details javadoc needs to include How we expect what class does & its
expected use What a method does & when it should be
called Given a methods actions, what method’s
results are Meaning of return values & any special
“magic” values List all possible exceptions & when it will be
thrown How to call method including examples
(with return)
Good javadoc
/** * Perform the basic work needed when a button is * pushed. This will illuminate the light in the * button. The first time a button is hit it will * also send a message to the elevator controller. */public void pushButton() { /* Code goes here… */ }
How Does javadoc Test Design? What if do not know enough to write javadoc? You can write code but cannot describe
what it does?
Good javadoc Yields Test Info/** * Perform the basic work needed when a button is * pushed. This will illuminate the light in the * button. The first time a button is hit it will * also send a message to the elevator controller. */ What are the inputs?
What is result given these inputs?
Are there special values we need to test?
Is This Method Really Usable?
What is the Goal Again?
Idea is NOT to read methods' code If comments are good, easier to understand
than Java Provide details users need to use method
or class For this to work must make it easy to
understand Show important connections to well-known
examples@see class @see #method @see class#method Explicitly state any "magic" param or return
values Provide examples to clarify how it will work
Now This I Can Use
Other Details To Describe
State all assumptions to prevent future bugs When calling this method, do any side
effects occur? Built-in assumptions upon which method
relies Once method completes, details needed for
later
Programming By Contract
Precondition true at start when method called Ensuring these met responsibility of calling
method Postconditions true at end of the
method call Guaranteeing this responsibility of called
method Only if preconditions met must this
happen, however
Good Documentation Example
/** * Perform the basic work needed when a button is * pushed. This will illuminate the light in the * button. The first time a button is hit it will * also send a message to the elevator controller.<br/> * * Precondition: lit.isOff(); controller is set<br/> * * Postcondition: !lit.isOff() && * request sent to elevator controller */public void pushButton() {}
What's Next?
Could start to write code at this point in project But doing this means still may find many
bugs Fixing these hard if calling many other
methods Ideal if we could 1st check that method
actually works Remember key trait of successful
programmers
Outlining a Method
Write pseudocode outline of how method works Include calls to other methods assuming
they work Should not be code, but simpler & easier to
write Can then use tests to check that algorithm
works Fix errors BEFORE coding to limit
debugging needs Write method starting with outline as
comments Process limits where bugs exist since
algorithm works First step is to check that test written
correctly & valid Check code versus algorithm & make sure
lines match
Heated Handlebars
For Next Lecture
Week #2 homework available on Angel page Due by 5:00PM on Tuesday (as will be
usual) Submit assignment via e-mail & (possibly)
paper Reading for Friday linked to from Angel
schedule Discuss range of possible tests to perform How often to test code as we are writing it Present methods of handling failed test