1 / 16

Structured Laziness

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.

otto
Download Presentation

Structured Laziness

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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)

More Related