Tuesday, October 31, 2006

Coding Horror: Properties vs. Public Variables

Why waste everyone's time with a bunch of meaningless just-in-case wrapper code? Start with the simplest thing that works-- a public variable. You can always refactor this later into a property if it turns out additional work needs to be done when the name value is set. If you truly need a property, then use a property. Otherwise, KISS! Update: As many commenters have pointed out, there are valid reasons to make a trivial property, exactly as depicted above:

* Reflection works differently on variables vs. properties, so if you rely on reflection, it's easier to use all properties.

* You can't databind against a variable.

* Changing a variable to a property is a breaking change.

Source: Coding Horror: Properties vs. Public Variables

So this answers the question on why you use properties in .NET and not just public variables.

I've always used properties but on occasion of used public variables. Small object, needed it quick so didn't bother with the getter or setters.

I work with a Java developer who abhors getters and setters, says it is Microsoft's way of disguising method calls. I disagree since I don't think the overhead involved is that great.

As far as creating the getters and setters, hey, that is what code snippets is for.

Thursday, October 26, 2006


Ok, so I found another alternative to BlogJet: Performancing.  This is an extension of FireFox so I have to have that installed.

So far it looks like it is easy to use.  It can't seem to be able to insert an image like Live Writer but I think it will be easier to blog about something I found on the web.

I have a feeling I will keep using Live Writer and only use this on occasion.

powered by performancing firefox  OK I don't like that Performancing does self promoting.  That is a big minus.

Sunday, October 22, 2006

Windows Live Writer

So I just heard about the Windows Live Writer Beta.  I am a big fan of BlogJet so when I heard about this new Microsoft program I was skeptical.  So far I like it.

Now if it uploads this picute then I will have a reason to start using it and not use BlogJet.

I am always on the lookout for new and better tools.  If this does what I need it to do then I will switch to it.

Tuesday, October 17, 2006

SQL Moment of Clairity

I was working on a stored procedure the other day, not one that I wrote originally but one that was causing performance issues in out system. The procedure was taking any where from 40 to 60 seconds to run, which is unacceptable in a web service. This in fact was causing the web service to time out.

An inspection of the execution plan showed that one part of the procedure was doing an index scan and that it was this that was taking up over 85% of the execution time. I was totally baffled, it was hitting the index so why wasn’t it faster?

Then I learned three things all at once:

  • Implicit Conversion

  • non-sargable kills performance

  • Index Seek is preferred of Index Scan

Implicit Conversion

In the stored proc a variable was defined as an NVARCHAR(20) but the field in the table it was being compared to was a CHAR(10). This lead to an implicit conversion of the variable to a CHAR(10), which lead into the next issue:

Non-Sargable Kills Performance

Sargable refers to the pseudo-acronym “SARG” – Search ARGument and refers to a WHERE clause that compares a constant value to a column value. The implicit conversion was causing a non-SARGable condition which means the WHERE clause cannot use an index.

Index Scan

Because of the non-sargable condition an Index Scan was being performed. An Index Scan is just as bad as a Table Scan in the SQL realm and should be avoided at all costs.

The solution was simple: Change the variable to a CHAR(10). After doing that the Index Scan became an Index Seek and the whole stored procedure returned in less than a second. Any time I see an order of magnitude improvement like that from one simple change it just boggles my mind.

Friday, October 06, 2006

Ralf's Sudelbücher : .NET naked - See these hitherto unpublished pictures of the .NET Framework architecture

The other day, though, I stumbled over yet another software quality assessment tool: Lattix LDM. And what impressed me immediately was it´s easy to understand output based on the intuitive concept of the Dependency Structure Matrix (DSM).

Ralf's Sudelbücher : .NET naked - See these hitherto unpublished pictures of the .NET Framework architecture.

Ralf demonstrates how a Dependency Structure Matrix can reveal the overall architecture quality of a product.  A very cool concept and another tool to add to the toolbox.