Structured Laziness

1
Structured Laziness

• PAUG Presentation
• August 2002

2
About The Speaker

• Sam Gray (samgray_at_timestream.net)
• Since April 2001, I work for Jerry Porter (last
  months speaker) at Personable PC Solutions.
• I have been doing VB/VBA development for about 4
  years.
• I have been doing public speaking for about 1
  minute.

3
About This Talk

• I call this talk Structured Laziness because I
  hate the phrase best practices but thats
  really what its about. ?
• I will present several tips that have helped
  reduce my overall expenditure of effort (YMMV).
• Some come from things Ive taught myself, some
  from Smart People Ive worked with.
• Oriented toward intermediate developers, but I
  will show almost no actual code.
• Feel free to ask questions as we go, especially
  if what I say is unclear. If I cant answer them
  quickly, Ill ask you to raise them again at the
  end.

4
Did He Say Laziness?

• According to Perl folklore, the three great
  virtues of a programmer are Laziness, Impatience
  and Hubris (in that order).
• I define laziness as wanting not to solve the
  same problem more than one time or in more than
  one way.
• These tips may seem like more work to
  implement.I had to be dragged into doing some of
  them myself! In the long run, though, they have
  saved me time.

5
A Geek Shall Inherit Your Code

• Most of these tips are essential for dev teams.
  Individual developers should still remember these
  principles
• You wont always maintain the project Someone
  Else (teammate or successor) will eventually need
  to understand it. Make their job easier.
• Even if you will always maintain the project, you
  wont remember what you were thinking when you
  come back to it. (You Time Someone Else)
• If you always do the basic (boring) things in a
  consistent way, you can concentrate on the
  interesting parts of your job.

6
1) Think Fast, Type Slow

• Design Happens whether you plan for it or
  not.So you might as well plan for it.
• Design new code (or changes to existing code)
  before you write it, using Word or a text editor.
  Include at a minimum
• Data structure (rough outline is OK in Access
  its just as easy to simply make the changes as
  to do field-level design in a textfile)
• User interface
• Code structure (OOP or procedural, may include
  pseudocode)

7
2) Dont Break The Interface(and if you must,
dont leave it broken for long)

• Interface OOP term meaning a list of methods an
  object must implement. I also use it to mean
  the list of parameters a procedure will accept
  (aka its signature).
• The code may not work, but it should at least
  compile (in case you have to check it in in a
  hurry).
• The compiler is your friend, esp. with Option
  Explicit on.
• If your design (you did a design, right?)
  requires you to change the parameters of one or
  more procedures, do that part first. 2 reasons
• Good opportunity to check your design
• Youll have all the variables you need when you
  start changing the rest of the code

8
3) Refactor Like Crazy

• Never copy and paste code!(No more than about 3
  lines.)
• If you find yourself copying code from one place
  in your project to another, thats a sign that
  its time to turn that code into its own
  subprocedure.
• Dont worry about the call stack (unless youre
  using recursion) Access can handle it.
• Remember 2 (Dont Break The Interface).

9
4) REMind yourself

• Write code that tells you what its doing and
  why!
• Use meaningful procedure names
  CalculateAgentCommissions() vs. Comm()(If you
  cant come up with a good, concise procedure
  name, thats another hint that its time to
  refactor.)
• Comment everything!
• Put a general description in header of every
  procedure.
• Include meaningful comments on their own lines
  for each logical section of code.
• Use end-of-line comments for complex or
  non-obvious operations.
• Use Enum (2000, XP) to avoid magic numbers

10
5) To Err Is Human. To Handle...

• Every procedure should have error handling (or a
  comment explaining why not).
• Your error handler doesnt have to be fancy
  just enough to save the error number, error text,
  and procedure name to a table or textfile, then
  exit gracefully (or continue if its minor, as in
  our DontContinue procedure).
• One of my own barriers to doing this was the
  thought involved. Doing this the same way every
  time is much easier, which is where a template
  comes in handy (next slide). Extra geek points
  for making an add-in.

11
Procedure Template

• Public Sub ProcedureName()
• '
• ' procedure header
• '
• On Error GoTo ErrHandler
• main code goes here
• ExitLabel
• Exit Sub
• ErrHandler
• LogError "ProcedureName"
• Resume ExitLabel
• End Sub

12
6) Check It Out (and In)

• Use a source control system.
• This doesnt have to be Visual SourceSafe,
  although thats good. You can roll your own
• Work with a copy, then back up the old version.
• Can be as simple as a set of batch files
• We use our own Access form that copies all files
  for a particular project, automatically creates a
  backup on check-in, and keeps a log of all
  copies.(example Some changes I had made got
  wiped out recently, but I was able to use the log
  to blame Jerry for doing it!)

13
7) Leave A Trail

• Maintain a change log and use it
  religiously.Ours is relational

Spec Bug / Feature Description (overview) Date
done Version implemented Author Comments Category
Etc
Individual changes File (multi-MDB
projects) Object Procedure Author Date Change
description
14
8) Trust No-One Especially Yourself

• Test new code before putting into production.
• Have other developers review your code before you
  check in your change.
• Work solo? Put it aside and go to lunch. Come
  back and review it once youve forgotten how it
  works. When you do, assume everything is wrong.
• You will forget to record a change. Plan for it.
• Consider writing your own comparison tools (esp.
  for table structure its easy to forget a change
  to Indexes). Can also use code reviews to catch
  this, if reviewer is good.

15
Other Tips

• Insert breakpoints or Stop statements in every
  execution path and remove them as they get used.
  If any are left when you think youre done, check
  your If conditions.
• Mark temporary code sections or temp comments
  with an easily-searchable string (we use 'temp),
  and remove all before checking in.
• Use Find And Replace, a useful add-in (29,
  http//www.rickworld.com)

16
Thank You!

• Questions?Sam Gray (samgray_at_timestream.net)