What every dev must know about URL Encoding.

I recently stumbled on one of Stéphane Epardaud's tech notes on URL encoding pitfalls and can't recommend it enough.

Let's see how this translates in the .Net world.

Open letter to whoever uses DebuggerStepThroughAttribute

AA+ Coder, would debug again. 

Or not actually. The [DebuggerStepThrough] attribute will, true to its name, instruct debuggers not to step through code contained in the method or constructor it is applied on. This can lead to hours of fun when debugging poorly documented code.

But Florian, you silly monkey, you will see this in the method signature! Will readers interject, to which I would have to reply "not if the method is more than a screen-long and I'm just checking uses of another type/method using Resharper or any fancy code-navigation tool."

The [DebuggerStepThrough] attribute has been there since day 1 of the .Net framework, but should have been kept internal to mscorlib as were 99% of the nice-to-have-but-very-dirty classes that make up most of the .Net framework. This attribute was used to prevent Visual Studio from stepping into the framework and either requesting the source code or treating you to some nice IL. Now of course the .Net framework is released under a shared-source license so you can step through it (most of it, mscorlibs, which accounts dor 75% of the core distribution).

Another misleading friend is the [DebuggerDisplay] attribute, which, when applied on a field or property, will change the name/value reported in the watch window. Apart from cheeky attempts at obfuscation and a slew of practical jokes (turning an int to NaN would be a good one on the top of my head), one would be tempted to use a formatting string with no arguments to protect from famous cases of the debugger auto watch causing side-effects when calling property getters (another form of Heisenbugs).

One way to do this would be :

using System;
using System.Diagnostics;

namespace OneKStrongOxen
 public class Runner
  public static void Main(string[] args)
   DebuggerDemo me = new DebuggerDemo();
   Console.Out.WriteLine("Breakpoint set " + me);
 class DebuggerDemo
  [DebuggerDisplay("These are not the droids you're looking for")]
  public string DangerousProperty
    Console.Out.WriteLine("Property getter invoked with side effects");
    return "DangerousProperty";
But sadly, although the display string doesn't contain any reference to the "{DangerousProperty}" format string, the property getter is still invoked...Long story short, if you consider using Debuger*Attribute you're either:

  1. Misled
  2. Overly confidend in the frameworkyness of your code and its quality.
  3. A Microsoft employee working on a non-shared-source API.

One of my current clients used to employ the services of a #2. Emphasis on used.
The solution to the above Heisenbug is either

I prefer the former.

Avoid boxing of structs implementing an interface

Structs are often used in situations where performance is critical, and are very powerful, but as the wise men say, with great power comes great responsibility and for value types, the responsibility is on the developer to make sure no boxing will occur.

The CLR states that when a value type is assigned to an interface reference, it will automatically be boxed, and boxing value types is bad.

This is what occurs in the following snippet (and how to solve this performance conundrum)

Stuck in 2.0 : Use Extension methods in .Net Framework 2.0

Some projects are still stuck in a 2.0 world and can't be upgraded to 3.5 due to weird build issues, does that mean you cannot use your String.Format shortcut extension method? Most assuredly not, thanks to an old trick to make the .Net 2.0 c# compiler accept extension methods.

In the name of all of us who occasionaly have to stare back to the past, "Thanks Daniel!"

.Net 4.0 profiling hurdles

Very good article about profiling in the .Net 4.0 framework by David Broman.

It seems like most profilers will have to release a CLR 4.0 update to their products,
JetBrain is actively testing alphas of DotTrace, still waiting for an official release date.

C# benchmark tool

After the last post on .Net 4.0 StringBuilder vs .Net 2.0 StringBuilder I realized I often ended-up testing different strategies for efficiency and I'm a little bit tired of rewriting the same .Net benchmarking framework, so here it is.

I use this when I need to check the execution speed and memory consumption of a piece of C# code, usually with pretty consistent results. The idea is to have a piece of code running in an environment where timing and memory use are monitored, and making sure the data collected isn't skewed by the JIT kicking-in or the GC stalling everything.

Here's the StringBuilder post rewritten to use this framework. Each method in the loop will be passed the object the initer fired, and the current iteration/max iter values.

.Net 4.0 StringBuilder implementation change : StringBuilder is now a linked list

An interesting change in the .Net 4.0 framework is the new System.Text.StringBuilder implementation. The .Net 1.0-era version has been ditched (it was basically an unsafe string* with an exponential memory allocation strategy on append).

The new implementation is actually a linked list of StringBuilder instances, with the current instance pointing to the last part of the string. This strategy favors insertion speed as the list always point to the latest piece of data that was inserted (it's a reversed linked list if you will).

Let's dig deeper in the implications of the .Net 4.0 System.Text.StringBuilder implementation.