Welcome to MSDN Blogs Sign in | Join | Help

Browse by Tags

All Tags » Design   (RSS)
Tuesday, February 12, 2008 1:54 AM

Why are you caching data?

There are multiple reasons to cache data. For example, are you caching because of a performance issue of because of a correctness issue? Know which, and comment it at the spot doing the cache. If it's performance, the idea is that you have some expensive
Posted by jmstall | 0 Comments
Filed under:
Wednesday, January 30, 2008 8:10 AM

Why threading is hard

Anybody who says "I can write correct multi threaded code" probably should be saying "I don't test my multi-threaded code". It is very difficult to write correct multi-threaded code. One way to appreciate this is various "find-the-bug" pop quizzes that
Posted by jmstall | 8 Comments
Filed under:
Wednesday, October 24, 2007 12:00 PM

Simple Tool for text substitution plus Design questions

I wrote a simple C# app to do text substitution. It takes a (key,value) mapping and then replaces any keys in between {% ... %} with their value. It's a really trivial app. But it also quickly opens a Pandora's box of design questions. It takes an xml
Posted by jmstall | 2 Comments
Filed under: ,
Sunday, August 05, 2007 12:26 AM

Making "Required properties" less annoying

Be wary of "required" properties that must be explicitly set correctly in order for the object to function (especially if it's not obvious). I recently got burned by this, and it's certainly a frustrating problem to diagnose. In my case, the function
Posted by jmstall | 2 Comments
Filed under:
Saturday, October 14, 2006 3:02 AM

Questions you should ask before using a callback / delegate

I just got burned by using callbacks in a multi-threaded app. I've rewritten the part to avoid callbacks, but for my good-deed-of-the-day, I wanted to issue a word of warning. Before you can safely use a callback / delegate / virtual function, particularly
Posted by jmstall | 5 Comments
Filed under:
Thursday, September 28, 2006 3:06 AM

How to start a console app in a new window, the parent's window, or no window

The ProcessStartInfo.CreateNoWindow property says "Gets or sets a value indicating whether to start the process in a new window." and later " true to start the process without creating a new window to contain it; otherwise, false . The default is false
Posted by jmstall | 4 Comments
Filed under: ,
Friday, September 01, 2006 4:31 PM

How can you force clients to use your APIs properly?

It's tough to make a client use your API correctly. It's especially tough to get clients to not do things that appear to work 90% of the time, but aren't correct and break down in that remaining 10%. It's even harder for things that work 100% of the time
Posted by jmstall | 2 Comments
Filed under:
Wednesday, August 30, 2006 11:40 PM

An example of an API versioning problem.

Here's an example of an API versioning problem. In general: Anytime you take two separate concepts and tie them together based off some current implementation assumption, you're going to get trouble when that assumption is broken. The specific example
Posted by jmstall | 4 Comments
Filed under: ,
Thursday, February 09, 2006 4:00 PM

Passing Property values by reference

I was wondering how well properties were integrated into C#. For example, C# lets you use += with the properties. It's easy enough to convert: MyProperty += 4 to MyProperty = MyProperty + 4 However, C# won't let you pass a property in as a ref parameter.
Posted by jmstall | 16 Comments
Filed under:
Wednesday, February 08, 2006 1:37 AM

Design Implications from boring details

You can discern a lot of information about an API from what appear to be subtle or irrelevant details For example, each ICorDebug object has a logical parent. (See here for a brief explanation of the different ICorDebug interfaces). Here's a chart: ICorDebugProcess
Posted by jmstall | 2 Comments
Wednesday, January 25, 2006 11:06 AM

What to do with a feature that only works 90% of the time?

Imagine when you're designing a feature if there was an operation that was very useful 90% of the time; but the other 10% of the time it was provably and innately unsafe (either crashed, deadlocked, or gave back garbage). By "innately unsafe", I mean
Posted by jmstall | 1 Comments
Filed under: , ,
Sunday, November 06, 2005 12:36 AM

Our policy on policy

... is that we don't want the platform making policy decisions. In general, any time the platform makes an arbitrary policy decision, half of our clients will think it's the wrong one. This why we're trying to shift our architecture focus to enabling
Posted by jmstall | 0 Comments
Filed under:
Tuesday, October 25, 2005 12:38 PM

Document properties that don't round-trip.

I personally think most API documentation is lame and either leaves critical behavior qualities unspecified, or don't comment when standard assumptions may be broken. One example is not documenting object lifespans . Another example is that you'd normally
Posted by jmstall | 12 Comments
Filed under:
Thursday, September 29, 2005 10:00 AM

Enable vs. Implement

There's a key distinction between a platform (like the CLR debugging services) enabling a scenario instead of actually implementing the scenario. Implementing a scenario means we provide specific functionality for a scenario. For example, the CLR debugging
Posted by jmstall | 0 Comments
Filed under:
Wednesday, September 14, 2005 1:59 AM

Types of Names

We've had some design discussions where we've come across 4 types of string names. These terms came mostly from discussing debugging symbols, but they extend to naming in general. Type Example for function Example for filename Fully qualified names (FQN):
Posted by jmstall | 0 Comments
Filed under:
More Posts Next page »
 
Page view tracker