Structured laziness
1 / 16

Structured Laziness - PowerPoint PPT Presentation

  • Uploaded on

Structured Laziness. PAUG Presentation August 2002. About The Speaker. Sam Gray ( 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 am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Structured Laziness' - MartaAdara

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Structured laziness l.jpg

Structured Laziness

PAUG Presentation

August 2002

About the speaker l.jpg
About The Speaker

  • Sam Gray (

  • 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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
Procedure Template

Public Sub ProcedureName()


' procedure header


On Error GoTo ErrHandler

‘ main code goes here


Exit Sub


LogError "ProcedureName"

Resume ExitLabel

End Sub

6 check it out and in l.jpg
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 l.jpg
7) Leave A Trail

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


Bug / Feature*

Description (overview)

Date done

Version implemented





Individual changes:

File (multi-MDB projects)





Change description

8 trust no one especially yourself l.jpg
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 l.jpg
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,

Thank you l.jpg
Thank You!

  • Questions?Sam Gray (