Structured Laziness

PAUG Presentation

August 2002

About The Speaker

Sam Gray (samgray@timestream.net) Since April 2001, I work for Jerry Porter (last

month’s 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.

About This Talk

I call this talk “Structured Laziness” because I hate the phrase “best practices” – but that’s really what it’s about.

I will present several tips that have helped reduce my overall expenditure of effort (YMMV).

– Some come from things I’ve taught myself, some from Smart People I’ve 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 can’t answer them quickly, I’ll ask you to raise them again at the end.

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.

A Geek Shall Inherit Your Code

Most of these tips are essential for dev teams. Individual developers should still remember these principles:

You won’t 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 won’t 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.

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 it’s 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)

2) Don’t Break The Interface(and if you must, don’t 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– You’ll have all the variables you need when you start changing the

rest of the code

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, that’s a sign that it’s time to turn that code into its own subprocedure.

Don’t worry about the call stack (unless you’re using recursion) – Access can handle it.

Remember #2 (Don’t Break The Interface).

4) REMind yourself

Write code that tells you what it’s doing – and why! Use meaningful procedure names:

CalculateAgentCommissions() vs. Comm()(If you can’t come up with a good, concise procedure name, that’s another hint that it’s 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”

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

Every procedure should have error handling (or a comment explaining why not).

Your error handler doesn’t 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 it’s 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.

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

6) Check It Out (and In)

Use a source control system. This doesn’t have to be Visual SourceSafe,

although that’s 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!)

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

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 you’ve 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; it’s easy to forget a change to Indexes). Can also use code reviews to catch this, if reviewer is good.

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 you’re 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)

Thank You!

Questions?

Sam Gray (samgray@timestream.net)