Tim Gifford

Development Philosophy

Purpose:
The purpose of this document is to convey some simple ideas and practices that I have found helpful in a team development environment.

I’m using the term “Ideals” to communicate the fact that these are not “rules”. They are flexible and not appropriate for every situation.

Ideals:

• Code Intuitively
  Comments are good, but too many comments means the code is too difficult to understand
  
• Acronyms are evil
  I LOL when IC 2 many acronyms in code, IMHO. I would like to have an acronym for E.V.I.L to help reinforce my point.
  
• Use Strongly Typed Objects
  A string is a string, and a date is not a string.
  Strongly typed objects will catch more errors at compile time than “late bound“ objects or generic datasets.
  
• High Cohesion
  Prevent “Object Envy”. “Object Envy” occurs when an object constantly calls to another object to perform a method or get data.
  
• Loose coupling
  Minimize dependencies within your system. This can be difficult especially when trying to user strongly typed objects.
  
• Static/shared methods are evil
  
• Use interfaces for behaviors
  
• Unit Test everything
  Design for unit tests – this will help decouple the system
  
• Make objects as dumb as possible, and no dumber
  
• Put your software “on wheels”
  Design your application to be easily deployed. Over it’s lifetime your application will be moved to another server. Make it easy to move.
  
• Collective Ownership
  All developers own all the code in the system. Each developer has the right and duty to repair any broken code as long as there changes compile and all unit tests pass successfully
  
• Minimize locks on project files
  
• Continuous Integration
  Integrate your code with other system instantaneously
  
• Use Globally Unique Identifiers (GUID) for keys
  
• Business Logic belongs in the business layer
  
• Security through obscurity is NOT security
  
• Security is “Bake In” not layered on
  
• Exception Handling
  Only catch errors you know how to handle (Never Catch System.Exception)
  I know you are freaking out right now, but let me explain. Exceptions are for things that your code understands how to handle. Does your code know how to handle a System.OutOfMemoryException? How about a System.StackOverflowException? If not, you should try to catch them.

  These lines of code will make it appear that no exception was thrown:

            Try
                'Do Something
            Catch ex As Exception
                System.Diagnostics.EventLog.WriteEntry("MyCode", ex.Message)
            End Try

posted @ Friday, July 08, 2005 8:06 PM