lecture 4: coding in groups

22
LECTURE 4: CODING IN GROUPS MKT 101 – Introduction to Marketing Why should I learn about marketing? I’m in CSC to avoid this!

Upload: davin

Post on 23-Feb-2016

33 views

Category:

Documents


0 download

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 Presentation

TRANSCRIPT

Page 1: Lecture 4: Coding  In Groups

LECTURE 4:CODING IN GROUPS

MKT 101 – Introduction to Marketing

Why should I learn about

marketing?I’m in CSC to avoid

this!

Page 2: 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 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?

Page 3: Lecture 4: Coding  In Groups

Time Required To Understand

Atte

ntio

n Pa

idHow My Homies Roll

Page 4: Lecture 4: Coding  In Groups

Reactions to Your Code

Time Spent

Use

r’s

Abili

ty

Passion Threshold

Suck Threshold

Page 5: Lecture 4: Coding  In Groups

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

Page 6: Lecture 4: Coding  In Groups

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

Page 7: Lecture 4: Coding  In Groups

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?

Page 8: Lecture 4: Coding  In Groups

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

Page 9: Lecture 4: Coding  In Groups

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)

Page 10: Lecture 4: Coding  In Groups

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… */ }

Page 11: Lecture 4: Coding  In Groups

How Does javadoc Test Design? What if do not know enough to write javadoc? You can write code but cannot describe

what it does?

Page 12: Lecture 4: Coding  In Groups

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?

Page 13: Lecture 4: Coding  In Groups

Is This Method Really Usable?

Page 14: Lecture 4: Coding  In Groups

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

Page 15: Lecture 4: Coding  In Groups

Now This I Can Use

Page 16: Lecture 4: Coding  In Groups

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

Page 17: Lecture 4: Coding  In Groups

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

Page 18: Lecture 4: Coding  In Groups

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() {}

Page 19: Lecture 4: Coding  In Groups

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

Page 20: Lecture 4: Coding  In Groups

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

Page 21: Lecture 4: Coding  In Groups

Heated Handlebars

Page 22: Lecture 4: Coding  In Groups

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