L15cs2110fa09-6up - 10/20/2009 2 Designing and Writing a...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
10/20/2009 1 DESIGNING, CODING, AND DOCUMENTING Lecture 15 CS2110 – Fall 2009 Designing and Writing a Program 2 ± Don't sit down at the terminal immediately and start hacking ± Design stage – THINK first ± about the data you are working with ± about the operations you will perform on it ± about data structures you will use to represent it ± about how to structure all the parts of your program so as to achieve abstraction and encapsulation ± Coding stage – code in small bits ± test as you go ± understand preconditions and postconditions ± insert sanity checks (assert statements in Java are good) ± worry about corner cases ± Use Java API to advantage The Design-Code-Debug Cycle 3 ± Design is faster than debugging (and more fun) ± extra time spent designing reduces coding and debugging ± Which is better? ± Actually, should be more like this: design code debug design code debug Divide and Conquer! 4 ± Break program into manageable parts that can be implemented, tested in isolation ± Define interfaces for parts to talk to each other – develop contracts (preconditions, postconditions) ± Make sure contracts are obeyed ± Clients use interfaces correctly ± Implementers implement interfaces correctly (test!) ± Key: good interface documentation Pair Programming 5 ± Work in pairs ± Pilot/copilot ± pilot codes, copilot watches and makes suggestions ± pilot must convince copilot that code works ± take turns ± Or: work independently on different parts after deciding on an interface ± frequent design review ± each programmer must convince the other ± reduces debugging time ± Test everything Documentation is Code 6 ± Comments (esp. specifications) are as important as the code itself ± determine successful use of code ± determine whether code can be maintained ± creation/maintenance = 1/10 ± Documentation belongs in code or as close as possible ± Code evolves, documentation drifts away ± Put specs in comments next to code when possible ± Separate documentation? Code should link to it. ± Avoid useless comments ± x = x + 1; //add one to x -- Yuck! ± Need to document algorithm? Write a paragraph at the top. ± Or break method into smaller, clearer pieces.
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
10/20/2009 2 Javadoc 7 ± An important Java documentation tool Java source code (many files) Linked HTML web pages javadoc ± Extracts documentation from classes, interfaces ± Requires properly formatted comments ± Produces browsable, hyperlinked HTML web pages 8 How Javadoc is Produced 9 /** * Constructs an empty <tt>HashMap</tt> with the specified initial * capacity and the default load factor (0.75). * * @param
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 03/08/2010 for the course CS 2110 taught by Professor Francis during the Spring '07 term at Cornell University (Engineering School).

Page1 / 7

L15cs2110fa09-6up - 10/20/2009 2 Designing and Writing a...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online