Effective Programming

1
Effective Programming
2
Why test?

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

http//slashdot.org/index.pl?issue20070225
3
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
• Dont 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 dont think this quote has any
  relevance to programming

4
Why refactor?

• Refactoring Making changes to your program that
  dont 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

5
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

6
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--dont let the code get out of control
• Writing tests before you write the code isnt 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
• Dont add features until the code you already
  have is completely debugged
• It takes discipline to follow these rules--its
  easier to just jump in and start writing
  code--but a methodical approach greatly increases
  your chance of success

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

8
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 havent
  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...
• Dont 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 doesnt 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

9
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 dont need them, you are better off
  without them

10
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 201
the ratio of debugging times over 251 of
program sizes 51 and of program execution speed
about 101. They found no relationship between a
programmer's amount of experience and code
quality or productivity.
-- Code Complete, page
548