Wednesday, March 5, 2008

Don't forget about string.IsNullOrEmpty() in .NET 2.0

I have noticed, in my travels though code written by others, that string.IsNullOrEmpty is simply being overlooked.

As most of you know by now, its much better practice, performance wise, to check if length of a string is less than or equal to zero, than comparing it to "" or string.Empty, when trying to determine if its an empty string or not. For those of you who didn't (yes you, in the back, I see you) here is a MSDN article that answers the question. Anyways, I digress and that's not the focus of this post.

The point is that in .NET 1.1 you did the classic:

if( someString == null || someString.Length <= 0 )
return;


Fantastic. However, typing that every time you want to do a "is the string empty check" gets old quite fast. Never fear - MS to the rescue of our ever precious keystrokes. It was decided that in .NET 2.0 that a static function, doing just the above, would become part of the public string interface and save us a little of the hassle.



Now the above code can be "simplified" as:

if( string.IsNullOrEmpty(someString) )
return;


It's a lot more expressive of intent, therefore more readable and as an added bonus, less of a pain to type (a massive 12 chars including white space ;P).



I have just noticed that a great deal of developers either don't now about it, simply don't use it or are still comparing strings to "", hence this post. Not exactly a "wow" or "this-going-to-change-my-life-forever-thank-you-so-much" post, but hopefully it will serve its purpose. It's just a little reminder to those who have made the move from 1.x to 2.0+ (or are just starting) that it's there... aching to be used.

Tuesday, March 4, 2008

The Object.Equals Gotcha

I haven't had the need to override the .Equals implementation on reference types all that much in my coding career. However, such a need sprang up earlier on today. While implementing it in the most rudimentary way, I just couldn't shake the feeling there was something that just didn't feel right. So I booted up Good 'ol Google and took a quick look at what was out there.

I came across this article that spells it out quite nicely (be sure to read the comments as well). Bottom line, if you are dealing with a reference type, its better to include an additional method on your public interface that will compare the contents for equality.

It's still a bit of a gray area for me. I am going to have to sit a while and mull over just what exactly the implications are, but these little bits of information are great to have stored in the back of your mind.

Friday, November 16, 2007

If only the truth was a base class...

I was having a discussion with a friend of mine and, as fate would have it, we managed a brief stint over the theory of truth and lies...
"Lie" is such a strong word - to alleviate this burden some think it's better phrased as "extending the truth". Now if only there was some technical implementation of this.... hmmmm....

Fear not! I have done it. Here it is in all its glory...

The truth as a base class.

(in C#)

   1: public class ExtenedTruth : Truth
   2: {      
   3:     public override string TellTheTruth()      
   4:     {          
   5:         StringBuilder sb = new StringBuilder(base.TellTheTruth());          
   6:         sb.AppendLine(" and we extend over here... ");           
   7:         return sb.ToString();      
   8:     }
   9: }


Done! All this without any lies involved. What a pleasure... :D


P.S. please notice the use of the StringBuilder so that we can append loads onto the "truth" with as little of a performance hit as possible.
P.P.S. I am pretty sure this would compile on the Mono framework.
P.P.P.S I think I need to patent this.


Monday, November 5, 2007

I hate those Permanent Temporary Failures...

This is one of those things that make you laugh on your Monday morning...

Let me set the scene for you. A few days back, I was attempting to send a file via email (gmail) to various recipients. It would send, but never reach its destination. Frustrating to say the least, especially when you take into account that 12 previous attempts had already been made.

Now the more technically savvy among you may say: "Why not just use FTP? Email is notoriously bad for reliably sending files, especially when its important..."

Bottom line - I couldn't. Lets just leave it at that and be done with it. Below is a snippet of the delivery failure I got from Google (obviously I changed the email address and bolded the important parts...).

*snip*
...
subject:
Delivery Status Notification (Failure)

This is an automatically generated Delivery Status Notification
Delivery to the following recipient failed permanently:
names.changed.to@protect.the.guilty
Technical details of permanent failure:
TEMP_FAILURE: SMTP Error (state 16): 451 qq temporary problem (#4.3.0)
  ----- Original message -----
Received: by
10.100.212.14 with SMTP id k14mr997577ang.1193785829292;
...
*snip*

Well, I thought it was funny... a permanent failure with a temporary problem. Sweet.

P.S. what is also quite interesting that Google marks those failure notifications, from itself, as SPAM. I'm not complaining, just an interesting side note.

Saturday, October 27, 2007

It seems Windows Live Writer has a problem with publishing...

any posting that has been assigned a category with an "!" in it.

For those of you who don't know, Windows Live Writer is a nifty little tool that allows us to blog away independent of the native blogging editors provided by the various different flavours of blogging software. I rather like it.

Aaaanyways...

I get the following little error notification when attempting to do so:

image

The software is still in beta, so little issues here and there are to be expected I suppose. The upside is that the software didn't crash and my post wasn't lost... just incase you were interested... ;)

When simple is just not enough...

We all have felt the pain at one time or another. Yes... you know it... its that warm fuzzy time when you have to maintain someone else's code.

Generally, its difficult enough to adapt your thought process/logic to that of someone else, however, the added fun comes when the person who actually created the masterpiece of code, did it with a complete disregard to any sort of afore mentioned logic.

Now please, don't get me wrong... I don't usually go around ragging on code that someone else has done to the best of his/her ability (in this particular case lets hope, for the sake of the creator, it was the result of something closer to an alcohol induced coma as opposed to a fair reflection of said ability), but sometimes, especially at 01:20 in the morning, having to sift through what can only be described as a waste of time, I am a little less in the forgiving mood...

I believe the following sums it up:

   1: CultureInfo cuInfo = CultureInfo.CurrentCulture;
   2: NumberFormatInfo numberFormatInfo = cuInfo.NumberFormat;
   3: string strNegativeSymbol = numberFormatInfo.NegativeSign;
   4: if ((dtbContract != null) && (dtbContract.Rows.Count > 0))
   5: {
   6:     decContracRate = Convert.ToDecimal(dtbContract.Rows[0]["PayoffAmount"],
   7:                        System.Globalization.CultureInfo.InvariantCulture);
   8: }
   9:  
  10: if ((decContracRate.ToString().IndexOf(strNegativeSymbol) > -1))
  11: {
  12:     btnPrintPayment.Enabled = false;
  13:     if (btnIsVoid.Enabled == true)
  14:     {
  15:         btnIsVoid.Enabled = false;
  16:     }
  17: }
  18: else
  19: {
  20:     btnPrintPayment.Enabled = true;
  21: }

Excluding all the other issues with this code snippet, unless I am missing something extremely sneaky - I am pretty sure the following would have done the trick:



   1: if( decContractRate < 0 )
   2: {
   3:     // oh look - its a negative
   4:     ...
   5: }

Yup... sometimes simple is just not enough...

The first posting...

Well... here it is. Finally. My first blog posting. I have been thinking about doing this for quite some time now.

Today, it seems, is that day...

Heaven help us all ;)

- Mike