C# coding style conventions

I like how the main body of the book is divided into 9 chapters, and Chapter 9 is followed by Chapter A. Some would consider it an appendix, others – a sequential hexadecimal numbering. Pretty neat.

As for the coding conventions, they don’t match my coding conventions, and therefore of course I don’t like them. I support or at least don’t mind most of the conventions specified, but there are some I specifically don’t accept. For starters, the curly braces are put like in Java:

[read more...]

Common Design Patterns

A number of “design patterns” are described in this section. I put the words “design patterns” in quotation marks, because the patterns are not described in a standard manner established by the GoF book.
[read more...]

This is part three of the series.

Type Design (continued…)

p 89: Struct design: DO ensure that a state where all instance data is set to zero … is valid. This sounds reasonable, until they give an example. They consider a structure

[read more...]

This is a second portion of my comments on the “Framework Design Guidelines” book. See also Part I. This post is devoted to the following recommendation we find on page 81 of the book:

DO favor defining (abstract) classes over interfaces

This is an often quoted guideline, that can be found in MSDN and elsewhere. It is probably the most controversial guideline in the book, especially given its near-mandatory strength (“DO”) as opposed to more lenient “CONSIDER”. The book itself contains descending opinions ranging from “I agree in general, but…” (Jeffrey Richter) to “you can see interfaces coming back” (Chris Anderson).

The author demonstrates this guideline on an example of the Stream class. “The System.IO.Stream abstract class shipped in version 1.0 of the framework without any support of timing out pending I/O operations. In version 2.0, several members were added to
Stream to allow subclasses to support timeout-related operations.”

public abstract class Stream
{
    public virtual bool CanTimeout { get { return false; } }

    public virtual int ReadTimeout
        { get { throw new NotSupportedException(); } }
        { set { throw new NotSupportedException(); } }
}

It’s been a long time – New Year, small vacation, etc…

Getting back to the blog. By the recommendation of my colleagues I took the Framework
Design Guidelines book in the library. This is an interesting book. Unlike some other books where “evangelists” throw at you empty slogans about things they hardly understand, the guys that wrote this book seem to know very well what they are talking about. Even if you don’t agree with everything they say, the book provides an insight into the philosophy behind the .NET framework. [read more...]