I was asked by someone recently what I would want to see in a code base that I may've recently inherited. As devs we certainly come across new code bases all the time, some big others small. Here are a few things that I would really like to see:

General code readability & maintainability:

• Use of consistent coding conventions
• Proper code formatting e.g. no extra spacing or unwanted line breaks (Note: it's easy to reformat code using editors these days though).
• Use of a source control system. Although I don't think anyone really develops without a source control these days (or do they?)

Setup and modularity:

• Functionality broken into multiple projects/assemblies
• Layered architecture to separate concerns
• Easy to map namespaces to an assembly. From personal experience, I feel this can cause a lot of confusion sometimes.
• Build script for the solution
• Deployment scripts and/or packages

Design:

• OO basics are applied (assuming an OO programming language is used) i.e. abstraction, encapsulation, inheritance, polymorphism
• Less depth in inheritance hierarchies. While I understand this can be hard to get away with in large applications I am against inheritance abuse.
• Design patterns
• (Any) SOLID principles in use. I would really like to see Single responsibility, Open/closed and Dependency inversion principles.
• No obvious code smell e.g. code duplication, God objects, spaghetti code etc
• Caching, paging and other general performance considerations in code and database queries
• Well known frameworks in use e.g. NHibernate, jQuery, log4net etc
• Error handling (where it makes sense) and logging

Testing

• Automated unit/integration tests
• Mocking frameworks in use
• Automated UI testing (if possible)

I'm sure there are other things that could make into this list.

I've blogged about using static constuctors for Singletonsbefore. Static constructors are invoked only once before any (instance or static) member of the class can be executed. Based on this behavior, it provides an ideal thread-safe initialization section in many scenarios.

There is however one particular behavior of static constructors that is good to know. If an unhandled exception occurs in a static constructor then the class is effectively unusable. Any other client code trying to use any static/instance member of the *failed* class can expect a type initialization exception in return. Unlike instance constructors, the runtime will not try to re-execute the static constructor if it failed once since static constructors are only supposed to execute once.

For developers it's something important to keep in mind if you tend to use static constructors frequently. Either explicitly handle the exception or try not to put any code in there that can result in an error e.g. a call to a DB or web service. Stuff like this should be put in a separate initialization method that should be called once.

Bulk copying is the preferred method for loading high volume data. The SqlBulkCopy API in ADO.NET provides the ability to bulk copy using interfaces that .NET developers are more accustomed to e.g. IDataReader and DataTable. It’s similar to the SQL BCP utility however it can provide much more control over the loads. Bulk copying performance over individual inserts is achieved mainly due to a few factors:

• Significant reduction in database round trips
• Minimal logging at the database level (under certain conditions)
• Reduced constraint checking by default

Contrary to popular belief, bulk copy operations can also participate in transactions. SqlBulkCopy has been working quite well for a high volume data loader I developed loading approximate 5 million rows daily on average. Here is an in depth research on SqlBulkCopy API behavior in different scenarios (thanks to the author for all the research): SqlBulkCopy Performance Analysis

Some notes from the article:

• SQL Server scales quite well for concurrent loads up to a certain threshold.
• Loading into a heap is must faster than an indexed table for obvious reasons. However if indexes are required then it maybe better (in some cases) to disable them during loading and enable them after.
• The batch size can impact performance. The bigger the batch size the better.