Month: June 2007

C# Design Guidelines

By peterritchie

Principles  Prefer explicit declarations to implicit declarations.  If you’re expecting something from a declaration, explicitly state it. Never depend on implicit side-effects. Never design cyclic dependancies, always design ascyclic dependancies. Prefer readability over complexity. Never optimize Always prefer the Prefer always implementing an empty constructor instead of no public constructor. There is a side-effect to not implementing any constructors: you get a public general constructor for free.  The drawback to that is if you add a non-general constructor your interface changes.  If something is already constructing your class that will introduce a compile error. Prefer internal on class declarations rather … Continue reading C# Design Guidelines

System.Collections classes are obsolete

By peterritchie

Collection classes like ArrayList, SortedList, Stack and Hashtable will shortly be obsoleted (i.e. the ObsoleteAttribute will be applied to them in upcoming .NET Framework builds).  You can start to see this in the Silverlight Alpha (i.e. the Obsolete attribute), but they will be physically unavailable in the release version. More details can be found in a recent Base Class Library Team blog entry Non-Generic Collections to be Removed from Silverlight. Even if you don’t plan on writing Silverlight-compatible code you should avoid using the types detailed in the BCL Teams blog because they’ll be obsolete in other future versions of … Continue reading System.Collections classes are obsolete

Performance Implications of try/catch/finally

By peterritchie

The accepted wisdom regarding performance of try/catch|finally in C# has normally been: try has no performance side-effects unless an exception is thrown.A discussion I was involved in recently caused me to discover some performance implications of try/catch blocks. The discussion revolved around protecting the volatility of certain members and the cross-thread memory ordering rules during run-time and during just-in-time compilation.  As it turns out, Microsoft’s x86 .NET 2.0 just-in-time compiler disables optimizations that would affect the CIL order of read/writes in protected blocks (AKA “protected regions”, “guarded blocks”, or “try blocks”).  As a result no optimizations are performed in try blocks. … Continue reading Performance Implications of try/catch/finally

The Religion of Class Member Prefixing

By peterritchie

The periodic identifier naming/prefixing/Hungarian-notation religious discussion reared its head recently on Eric Gunnerson’s blog.  This particular discussion revolves around the Microsoft-based guideline/anti-guidance of prefixing class member names with “m_” to denote that they are members.  I’ve contributed to many of these discussions over the years and thought it about time to encapsulate my separate remarks to which I and others can refer to. For the most part I accept this habit with my programmers for a variety of reasons: isn’t guaranteed to do any harm, it’s habit, refactoring tools make it easy to remove “m_”, etc. When I switched from … Continue reading The Religion of Class Member Prefixing

Software Design Priniples and Terminology

By peterritchie

Principles  Single Responsibility Principle An entity should have one, and only one, responsibility. Agile Software Development A methodology that espouses producing software by iteratively publishing subsets of functionality in working deliverables, acceptance of change throughout the development life-cycle, personal interaction with team members and stakeholders, and implements continuous improvement. Interface-oriented Design Object-oriented Design Aspect-oriented Design Law of Demeter A principle that improves quality by reducing coupling and increasing cohesiveness by mandating that the body of a method should only access argurments and their direct members, local variables and their direct members, and members of the containing class.  Sometimes referred to “only talk … Continue reading Software Design Priniples and Terminology

DateTime.ToUniversalTime *Should* Throw Exceptinos.

By peterritchie

A recent .NET Base Class Library blog post points out that DateTime.ToUniversalTime does not throw an exception for overflow values. This circumvents different Microsoft-sanctioned guidelines about using exceptions for exceptional situations, error reporting guidelines, not using return codes to communicate errors (which essentially what this is), the Method/TryMethod pattern, allowing the error to propagate to a level that knows how to deal with it, etc. I would recommend having overflows handled as exceptions and the addition of a TryToUniversalTime.  If the Method/TryMethod pattern is the favoured approach to providing two methods that result in the same thing–one without exceptions–this is impossible … Continue reading DateTime.ToUniversalTime *Should* Throw Exceptinos.