Zen and the Art of Code Design and Maintenance

Design Principles:

#1: Whenever you design anything, always do so from the user’s (consumer’s) viewpoint. If you are designing a framework, write examples of its intended usage; this will highlight any deficiencies.

#2: Encapsulate what varies. It should be possible to alter or extend the parts that vary without affecting everything else

#3: Program to an interface, rather than an implementation (i.e. exploit polymorphism). Use a factory.

#4: Favor composition over inheritance. Do not overuse inheritance; a blend of the two often works best.

#5: Don’t Repeat Yourself (DRY principle). Every fact must have a single, unambiguous, authoritative representation within a system.

#6: Aim for loosely-coupled designs between objects that interact. Low coupling and high cohesion lead to designs that are more resiliant to change.

#7: Classes should be open for extension, but closed to modification. Able to extend existing functionality without breaking existing code.

#8: Depend on abstractions, rather than concrete classes. Use a factory.

#9: Principle of least knowledge: talk only to your immediate friends. How? Only call methods on:

  • The object itself
  • Objects passed in as parameters to a method
  • Any object instantiated by a method
  • Any composite objects (Has-a)

#10: Low level components should never call into a high-level component directly.

#11: A class should have only a single reason to change (high cohesion)

#12: Raise Exceptions only in exceptional circumstances. Do not use exceptions for normal program flow.

(these are largely due to the excellent book ‘Head First Design Patterns’ by Freeman & Freeman, O’Reilly)

ASP.NET Video Tutorials: Another Free Resource

Came across this collection of ASP.NET videos ranging from beginner to stuff that’s ‘coming soon’:

Updated: might be more useful if I actually posted the link!

On this page you will find dozens of videos designed for all ASP.NET
developers, from the novice to the professional. If you are new to ASP.NET,
you can learn the basics of how to create dynamic web applications with
ASP.NET 2.0 and Visual Web Developer 2005 Express Edition, using either
Visual Basic or C#. If you have a bit of development experience, you
will learn how to employ some of the great new features introduced in
ASP.NET 2.0.

Greg Linwood visiting Perth – Sept 6th and 7th

September is shaping up to be a great month for the Perth developer community. Greg Linwood will be presenting two different sessions on SQL Server indexing on the 6th and 7th Sept.

The two sessions will be “Designing Indexes for Developers” (6th Sept) and “Managing Indexes for Database Administrators” (7th Sept). Although each session has a slightly different target audience, both have a common theme and will contain material that will be of interest to anyone who deals with SQL Server on a day-to-day basis. (I’ll definitely be attending both)

Both sessions will be held in the Colonial Ballroom – Melbourne Hotel, 942 Hay St (cnr Milligan St), starting at 5:30pm. Another 2 events not to miss!

A Few Tips on Becoming a Better Programmer

Are you setting out on your programming career? Do you want to be a better programmer? Here is a very short, set of guidelines (there’s nothing really new here, and it is not comprehensive, but if you are already following the majority of these then you are on the right track):

  • Be Consistent. Be consistent in everything you do. Periodically, examine the way you do things and the reason you do them that particular way; periodically re-assess to see if there are better ways.
  • Always name things as accurately as possible. If you find yourself unsure of how to name something, then you are probably unsure of its intended use. In the case of a class, it is often an indication that you should break it into smaller, multiple classes.
  • Always put yourself in the role of the user (= consumer). This Zen-like approach is ubiquitous: always design things from the point of the view of the consumer, regardless of who (or what) the consumer is. This includes frameworks, UI, objects, methods; basically everything! If you want an alterior motive, that consumer might be you in 6 months time!
  • Great software takes into account People, Process, Business, and Technology in that order.
  • Expect and design for CHANGE. Well designed software is flexible and resilient to changes in requirements. BUT do not over design. The art is in finding the right balance.
  • Never ‘invent’ your own encryption or random number algorithms (there are some classic coding horror stories of programmers rolling their own. This is an excellent article if you can find it: S. Park and K. Miller. Random number generators: good ones are hard to find. Comm. ACM, 31:1192—1201)
  • Never use Bubble sort! (and that means ever!) (see my previous blog entry)
  • Always use ISO date format when outputting dates as strings. This site is highly recommended reading.
  • Use and believe in testing. Use Nunit (or your platform specific xUnit) for unit testing. Watir is a good candidate for web UI testing.
  • The majority of runtime bugs/problems encountered are usually related to:
    (1) Permissions and Roles
    (2) Dates and Date Formats
    (3) Timing Issues
    (4) Configuration (which includes the previous 3 points)
  • When you have the choice of scripting a sequence of actions or just using an IDE tool to implement changes in an ad-hoc manner, ALWAYS script, script and script again!
  • When you are unsure of how something works, ask someone. There really are no stupid questions (only the ones you needed to ask but didn’t!).
  • Get a mentor (if you can). Either a senior programmer where you work or someone online. The online development community has flourished in the last 5 years and it abounds with talented people that give up their time to share best practices, such as Agile or Test Driven Development.
  • The software industry is somewhat unique with regards to the rate of change: if the thought of continuous change coupled with continuous learning throughout your career seems un-appealing then you should probably look for another vocation!
  • In my experience, the developers that write the fewest bugs tend to be the ones that have the smallest egos. When a bug is found in an application that includes your code, assume the bug is yours (within reason) and take responsibility for it. If it is yours it will probably be easier for you to fix than someone else, plus it is always easier to find out it is actually due to code written by someone else (help them fix it, the problem is still yours!), then to look foolish by pretending the problem lies elsewhere only to find it was you who made a silly mistake
  • When converting code between languages, be mindful of ‘off by one’ or boundary condition errors, as some languages have 1-based arrays by default. (I was going to remove this point as I wasn’t sure it was still as relevant, but having just found a subtle bug in converted code, I’ve included it).
  • Get closure on problems: bugs do not just go away! I have heard programmers actually say “Oh that bug?, it just went away!” This may be an indication that you are in the wrong profession! One trait that distinguishes good programmers is a burning desire to get to the root cause of problems.

Early last year (2005), I wrote a Powerpoint presentation that discusses steps you can take towards becoming a better programmer. I’ve delivered it at 2 companies, and it was well received. If anyone is interested, let me know and I’ll post it here.

MSDN Online Magazine: Another Great Free Resource

I’ve been a subscriber to the printed version of MSDN magazine for a number of years, and lately I’ve been wondering if I should continue, as most (if not all) of the content is available online here at msdnmag. The printed version usually arrives sooner, but by the time I get to it in my reading pile, the online version is already out! Maybe they should give it away to MCSD’s!

September’s issue has a wide range of articles including guidance for building smart clients, enterprise library custom application blocks and integrating Virtual Earth into your applications. There are also links to past issue articles such as preventing SQL injection attacks, crucial security tips for developers and a selection of performance related information.

Architecting Modern Desktop Apps in .NET

MSDN and Microsoft.com are full of great learning resources, but it’s not always obvious what’s available. Here’s a great series of webcasts Architecting Modern Desktop Apps in .NET by Dr. Joe Hummel (recorded third quarter 2005), describing the design and development of smart client applications.

There is also a series on Modern Software Development Using C#: Develop in .NET (with a equivalent series for VB.NET) at the same URL.

You will need to sign in to MS Passport to download these webcasts (and the 2005 offline player) and go through what seems like a ridulous number of clicks to download a single webcast (Microsoft: when are you going to make this processs easier, say download a complete series???). Who said the road to continuous improvement was supposed to be easy!

Always Use SCOPE_IDENTITY() in Stored Procedures

Now I’m sure most developers and DBAs are aware of this, but I mention it because it crops up every once in a while in production code. There are 3 ways to retrieve the last generated identity value for table: @@IDENTITY, IDENT_CURRENT(‘tablename’) and SCOPE_IDENTITY().

If you want to make sure that retrieved identity value is correct, use only SCOPE_IDENTITY().
In fact, it’s worth doing a search for the other 2 possibilities across all your projects’ stored procedures just to be sure.

From Books Online:

  • SCOPE_IDENTITY() returns the last identity value generated for any table in the current session and the current scope.
  • IDENT_CURRENT(‘tablename) returns the last identity value generated for a specific table in any session and any scope.
  • @@IDENTITY returns the last identity value generated for any table in the current session, across all scopes.