Scott Dorman

Sams Teach Yourself Visual C# 2010 in 24 Hours

Scott Dorman — Fri, 06 Nov 2009 04:01:43 GMT

I have previously mentioned that I’m working on the upcoming Sams Teach Yourself Visual C# 2010 in 24 Hours book.

Things are progressing nicely, if a bit slower than I’d prefer. I have the draft for the cover art, which looks really good.

I’m also very pleased to announce my technical editors – Claudio Lasaala and Eric Lippert.

Claudio is a Senior Developer at EPS Software Corp. He has presented several lectures at Microsoft events such as PDC and various other Microsoft seminars, as well as several conferences and user groups across North America and Brazil. He is a multiple winner of the Microsoft MVP Award and also holds the MCSD for .NET certification. He has articles published on several magazines, such as MSDN Brazil Magazine, CoDe Magazine, UTMag, Developers Magazine, and FoxPro Advisor.

Eric is a senior software design engineer at Microsoft has been working full time in the developer division since 1996, where he assisted with the design and implementation of VBScript, JScript, JScript.NET, Windows Script Host, Visual Studio Tools for Office and C#.

I am looking forward to working with both Claudio and Eric through the technical editing process and getting this book completed and available, which should happen sometime early in 2010.

Technorati Tags: Books,Sams Teach Yourself C# 2010

Visual Studio 2010 Beta 2

Scott Dorman — Mon, 19 Oct 2009 18:09:29 GMT

Visual Studio 2010 Beta 2 is now available for MSDN subscribers, and generally available on October 21. I haven’t had a chance yet to play around with it, but some of the CLR changes that are very exciting to hear about are:

The new String.IsNullOrWhiteSpace method indicates whether a string is null, empty, or consists only of white-space characters.
New overloads have been added to the String.Concat and String.Join methods that concatenate members of an IEnumerable<T> collections.
The String.Concat<T> method lets you concatenate each element in an enumerable collection without first converting the elements to strings.
The new Enum.HasFlag method determines whether one or more bit fields or flags are set in an enumeration value.
The Enum.TryParse<TEnum> method returns a Boolean value that indicates whether a string or integer value could be successfully parsed.
You can now easily copy one stream into another with the CopyTo method in classes that inherit from the System.IO.Stream class.
New Path.Combine method overloads enable you to combine file paths.
You can now parse System.Guid structures.
The new Microsoft.Win32.RegistryOptions enumeration lets you specify a volatile registry key that does not persist after the computer restarts.
Registry keys no longer are restricted to a maximum length of 255 characters.

I’m really looking forward to these improvements, particularly Enum.HasFlags, Enum.TryParse, String.IsNullOrWhiteSpace, Guid.TryParse, and Path.Combine(string[]). Of course, since some of these weren’t in Beta 1 (at least as far as I saw), it means revising some of the chapters for my book.

Technorati Tags: Visual Studio 2010,Beta 2,.NET 4.0

Interesting .NET Framework Statistics

Scott Dorman — Mon, 21 Sep 2009 01:15:01 GMT

I’ve been very “heads down” working on my upcoming book from Sams Publishing, Teach Yourself C# 2010 in 24 Hours, so I haven’t been blogging as much as I usually do. In doing some research for the book, I’ve been taking an in-depth look at the .NET Framework and thought I would share some interesting statistics.

There are 18,435 total types in the .NET Framework 3.5 SP1, with 13,995 classes, 1,216 interfaces, 2,100 enums, and 1,124 structs. The complete breakdown is shown below.

Of the 13,995 classes, 303 of them are exceptions. There are 227 public and 76 non-public exceptions. The complete breakdown is shown below.

Technorati Tags: .NET Framework

Premature optimization is the root of all evil

Scott Dorman — Sat, 29 Aug 2009 03:24:41 GMT

I’ve lost count how many times I’ve heard that quote. It’s a great quote said by one of the leading minds in computer programming and formal mathematics, Donald Knuth. The problem with this quote is that, like so many other things, people have only remembered (or only quote) a small portion of the entire thing.

To read the full quote, you need to look at a paper published in December 1974 titled Structured Programming with go to Statements in Computing Surveys.

The full quote is this (in reference to a loop optimization technique that provides a 12% performance improvement):

The conventional wisdom shared by many of today's software engineers calls for ignoring efficiency in the small; but I believe this is simply an overreaction to the abuses they see being practiced by pennywise-
and-pound-foolish programmers, who can't debug or maintain their "optimized" programs. In established engineering disciplines a 12% improvement, easily obtained, is never considered marginal; and I believe the same viewpoint should prevail in software engineering. Of course I wouldn't bother making such optimizations on a oneshot job, but when it's a question of preparing quality programs, I don't want to restrict myself to tools that deny me such efficiencies.

There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code
has been identified. It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been
that their intuitive guesses fail. (Computing Surveys, Vol. 6, No. 4, December 1974, p. 268 [p. 8 of the PDF])

While the overall sentiment could be summed up simply as “premature optimization is the root of all evil”, I think the point being made here is that well-known optimizations can and should be applied otherwise time spent on optimizing code should be focused on that small percent of critical code and should be performed with quantitative means.

What are well-known optimizations? That partly depends on your programming language and partly on your problem domain. Optimizations specific to a problem domain are very domain specific and not easily communicated outside of that domain. However, language specific well-known optimizations are a different story.

Take string concatenation inside a loop, particularly for languages like C# where strings are immutable objects. Why is that important? Since strings are immutable, they cannot be changed once created. When concatenating two strings you incur overhead from the creation of temporary strings. For example, consider the following code:

     string s = "this is " + "a test.";

While this is an arbitrary example, in order for this line to execute it would be necessary to create 3 strings. (Yes, I know the compiler (and if not the compiler, the JIT) would optimize this to remove the concatenation, but pretend for a moment that it didn’t.) Now, imagine this line running inside a loop 10 times. That loop has just created approximately 30 temporary string objects to perform that concatenation. In such a situation, it should be intuitive that the use of a StringBuilder to perform the string concatenation is preferable as you no longer have the intermediate string object creation and result in one allocation to create the StringBuilder and one allocation to convert the StringBuilder to an actual string object. There is always the possibility that while iterating through the loop the StringBuilder may need to perform a few additional buffer reallocations, but that still results in less overhead than creating immutable string objects.

The point here is that while it is true that premature optimization is the root of all evil, optimization should be a measured undertaking and well-known optimizations applied early are not premature.

Sams Teach Yourself C# 2010 in 24 Hours

Scott Dorman — Fri, 26 Jun 2009 23:54:33 GMT

I’m sure most of you are familiar with the Sams Teach Yourself books, at least in passing if not in owning one. I am very excited to announce that I will be joining the Sams Publishing authoring team for their upcoming Teach Yourself C# 2010 in 24 Hours book.

This new edition will be quite a bit different from the previous editions since it will be much more language-focused and will take a more holistic view of the language. If you have already looked at one of the earlier editions and decided that it wasn’t for you, please give the new edition a chance to change your mind; for those of you who already have an earlier edition, I hope this one will be of interest to you as well.

As it gets closer to the release date, I’ll be sure to let everyone know when it will be available.

I also want to thank Keith Elder, Shawn Weisfeld, Brad Abrams, and Krzysztof Cwalina for providing some excellent feedback on the table of contents.

Technorati Tags: Books,Sams Teach Yourself C# 2010