13-Jul-15 Effective Programming

“The new US stealth fighter, the F-22 Raptor, was deployed for the first time to Asia earlier this month. On Feb. 11, twelve Raptors flying from Hawaii to Japan were forced to turn back when a software glitch crashed all of the F-22s’ on-board computers as they crossed the international date line...every fighter completely lost all navigation and communications when they crossed the international date line. They reportedly had to turn around and follow their tankers by visual contact back to Hawaii...if they had not been with their tankers, or the weather had been bad, this would have been serious.” Why test?

Program design “In preparing for battle I have always found that plans are useless, but planning is indispensable.” --Dwight D. Eisenhower The same is true in programming You must plan out your program in advance, so you know where you are trying to go--but expect many changes along the way Don’t just jump into coding with the first approach that occurs to you, but consider alternate plans Always be ready to refactor as needed “How far you can go without destroying from within what you are trying to defend from without?” --Dwight D. Eisenhower Actually, I don’t think this quote has any relevance to programming

Why refactor? Refactoring: Making changes to your program that don’t affect what the program does Some refactorings: The name of a method no longer accurately describes what it does, so you want to rename it You need more control over what a method does, so you want to add a parameter You need to use only part of what a method does, so you extract that part into a separate method You realize that a method is in the wrong class, so you move it to a different class Eclipse makes these and other refactorings relatively “safe”-- that is, they are unlikely to break your program Not all refactorings are as easy

Regression testing Regression testing: Testing whether the program still works, after you have made a change to it JUnit tests are extremely useful for regression testing A thorough set of tests gives you the confidence to refactor Debugging is dangerous--fixing a bug is very likely to introduce new bugs It is a general rule that the difficulty of debugging a program goes up as the square of the program size

Programming discipline To write impressively good programs, here are some rules to follow Plan ahead--consider more than one design before you start programming Refactor early and often Test everything you can as thoroughly as you can--don’t let the code get out of control Writing tests before you write the code isn’t the only way to program, but it improves your program design as well as your code Start with “the simplest thing that could possibly work” Insofar as possible, make only small changes to your program Don’t add features until the code you already have is “completely” debugged It takes discipline to follow these rules--it’s easier to just jump in and start writing code--but a methodical approach greatly increases your chance of success

Dealing with I/O We can (in some cases) test our output methods PrintStream originalOut = System.out; OutputStream os = new ByteArrayOutputStream(); PrintStream ps = new PrintStream(os); System.setOut(ps); We can even test our input methods InputStream originalIn = System.in; byte[] buf = "Some input string".getBytes(); InputStream is = new ByteArrayInputStream(buf); System.setIn(is);

Dealing with GUIs GUIs are not easy to test with JUnit-like software There are programs that attempt to provide automatic JUnit tests for GUIs, but I haven’t found any I like If you want to write a GUI testing framework, you should explore java.awt.Robot There is a reasonably good, albeit not perfect, solution to the problem of testing GUIs... Don’t do any work in the GUI class! Use the MVC (Model-View-Controller) approach The GUI should only communicate between the user and the model Of course, this is easier said than done, but still.... Even if a GUI “works,” that doesn’t make it easy to use Of course you think your GUI is obvious You should always have at least one other person try it out without help from you--you will probably be surprised at the result

Creeping featurism “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” --Antoine de Saint-Exupery In my opinion (as you already know), the highest praise you can give to a program is to say “it just works” Unfortunately, most software competes on the basis of how many features it offers Sometimes you need those features When you don’t need them, you are better off without them

The End The original study that showed huge variations in individual programming productivity was conducted in the late 1960s by Sackman, Erikson, and Grant (1968). They studied professional programmers with an average of 7 years’ experience and found that the ratio of intitial coding time between the best and worst programmers was about 20:1; the ratio of debugging times over 25:1; of program sizes 5:1; and of program execution speed about 10:1. They found no relationship between a programmer’s amount of experience and code quality or productivity. -- Code Complete, page 548