1 / 22

Lecture 4: Coding In Groups

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

davin
Download Presentation

Lecture 4: Coding In Groups

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related