Re: [DotGNU]fxcop

[Miroslaw Dobrzanski-Neumann]

On Sat, May 01, 2004 at 06:51:35AM +1000, Rhys Weatherley wrote:
> On Friday 30 April 2004 10:59 pm, Miroslaw Dobrzanski-Neumann wrote:
> 
> > thus a == string.Empty is not an option
> > how about this replacement:
> >
> > if (a != null && a.Length == 0)
> 
> This will be relatively efficient when compiled with "cscc", but other C# 
> compilers will generate bad code for this too as they will call an overloaded 
> operator to do the initial null check.  You'd gain nothing over the original 
> 'if (a == "")'.  To be *really* efficient, you have to do the following:
> 
>     if (((Object)a) != null && a.Length == 0)
> 
> This avoids the overloaded operator, but now it is getting messy.  It is 
> worth 
> asking whether you are making the code unreadable for the sake of 
> performance.  Perhaps it would be better to change the order of the 
> surrounding algorithm so that you are doing less string comparisons in the 
> first place?
> 
> Was there a particular place in the code where you noticed this type of check 
> causing performance problems?  All systems spend 80% of their time in 20% of 
> the code, so if the string checks aren't in that 20%, then there's no point 
> making the comparison code messy.

I do not optimize my code at that level. If it runs too slow I look for
a better algorithm. Low level optimizations should be done by the compiler.

> 
> Just because a lint program says something is bad doesn't mean that it is 
> always bad.

The a == "" pattern appears so common an intuitive to me that I don't want any
other replacement. It reads better also; from the first glimpse I recognize
instantly what does a == "" mean. This is not the case with a.Length == 0 nor
a == string.Empty. For the obvious reason I expect the system to support such
cases at least as efficient as the sophisticated ones.

Regards
-- 
Mirosław Dobrzański-Neumann
E-mail: address@hidden

This message is utf-8 encoded