Lecture 4: Coding In Groups

1. Why should I learn about marketing? I’m in CSC to avoid this! MKT 101 – Introduction to Marketing Lecture 4:Coding In Groups

2. 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 JUnitor even writing tests • Important ways that projects started in real world • Documentation & testing are connected; how?

3. How My Homies Roll

4. Reactions to Your Code Passion Threshold Suck Threshold

5. Intuitive Is Key • 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 createdfrom unused parameters • Don't make user probe what method return means

6. 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

7. 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 • javadocdoes NOT need & should not include it • You may (or should be asking yourself): Why?

8. Why Not Include Details? • You writecode 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

9. 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)

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

11. How Does javadoc Test Design? • What if do not know enough to write javadoc? • You can write code but cannot describe what it does?

12. 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?

13. Is This Method Really Usable?

14. 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 examplesto clarify how it will work

15. Now This I Can Use

16. 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

17. 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

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

19. 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 1stcheck that method actually works • Remember key trait of successful programmers

20. Outlining a Method • Write pseudocodeoutline 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

21. Heated Handlebars

22. 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