Structured Laziness

1. Structured Laziness PAUG Presentation August 2002

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

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

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

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

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

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

9. 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”

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

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

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

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

16. Thank You! • Questions?Sam Gray (samgray@timestream.net)