Funny code

[snarfblam]

While translating some of my old VB to C#, I found this amusing line of code in a class I wrote a while ago.

If [U][B][I]Not Me Is Nothing[/I][/B][/U] Then
    Save(Medium.GetKey)
End If

I couldn't help but share this stunningly witty piece of code. It brings Descartes' famous quote to mind, "I think, therefore I am." Perhaps this is why I don't program for a living.

Anyone else?

 

[samsmithnz]

why would me ever BE nothing?

I think some of my early best code was something along the lines of:

If not blnIsNotaCustomer = true then
    'do [something]
end if.

Talk about confusing...

 

[Nerseus]

I like it

I wonder if anyone has some code like:
If Me.Exists() Then
' Do Something
Else
' Who cares - I don't exist!
End If

-ner

 

[PlausiblyDamp]

Makes you wonder why they didn't add a Something keyword to simplify the syntax...

If Me Is Something Then
    Save(Medium.GetKey)
End If

 

[snarfblam]

I like it

I wonder if anyone has some code like:

If Me.Exists() Then
' Do Something
Else
' Who cares - I don't exist!
End If

-ner

Actually, I have something similar, but this code actually does something more than confirm it's existence.

if(this.Exists()) {
	// Load settings if they exist.
	Load();
} else {
	// Default values
	_ProfRender = false;
	_DBPath = System.IO.Path.Combine(
		Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments),
		DataFolder);
}

This is the code used to initialize a settings manager class I wrote. The exists method returns whether or not the serialized settings exist.

 

[IngisKahn]

That looks like it belongs on thedailywtf.com

 

[Diesel]

I always thought the use of a g$ var in qbasic was funny. But then again, I have no life.

 

[kurf]

LoL WTFuk
I can't stand VB or VB.NET It allows to much non OO style programming!!!!!!!!!!!!!!!!!

 

[samsmithnz]

LoL WTFuk
I can't stand VB or VB.NET It allows to much non OO style programming!!!!!!!!!!!!!!!!!

What are you talking about. These examples would be the same in C# or Vb.

 

[mskeel]

LoL WTFuk
I can't stand VB or VB.NET It allows to much non OO style programming!!!!!!!!!!!!!!!!!

And the fact that the Object Class is at the root of the inheritence hierarchy is basically the epitome of Object Oriented... I've found that you have to go out of your way pretty hard to NOT be OO.

 

[sgt_pinky]

Yeh, even though now in .NET 2.0 they have the IsNot keyword, I still use the old If Not Blah Is Nothing syntax because it has grown on me

kurf, you need to go back to school or something if you honestly believe that. Show me how to NOT program OO in VB.NET!!!!

 

[snarfblam]

I never really appreciated the Is operator in the first place. I understand that it is there to avoid confusion between equal references and equal values, but people seem to get the right idea when using C#.

I actually started writing code like this when I switched over to C#:

// Before it occured to me to use the != operator for reference types
if(!(MyObject == e.Sender)) {
    // Do things and junk
}

 

[mskeel]

I never really appreciated the Is operator in the first place. I understand that it is there to avoid confusion between equal references and equal values, but people seem to get the right idea when using C#.

You do have to be careful, though. If you've overloaded the equals operator and you want to check for null references you have to cast the class object to type Object in order to make sure that you actually check the reference and not call the equals operator you wrote for the class object, which will fail for a null reference without the reference check. The is operator makes that casting unnecesary:

if ((object)mySuperObject == null)
{ 
   /* Do Something, probably return */
}

If mySuperObject is nothing Then
 ''Do Something, probably return
End If

And of course, the IsNot operator is pantented technology. Go figure how that happened (not trying to change subject).

 

[Cags]

I'm just as intruiged as to how you knew it was patented as to how it became patented. I must admit that as I'm used to c# I sometimes get caught out by the use of the 'Is' operator. I'm normally alright if I think through a statement carefully but if I just give it a cursory glance I often get the wrong idea. Especially when I was making a TypeConverter and using GetType and TypeOf.

 

[snarfblam]

You do have to be careful, though. If you've overloaded the equals operator and you want to check for null references you have to cast the class object to type Object in order to make sure that you actually check the reference and not call the equals operator you wrote for the class object, which will fail for a null reference without the reference check. The is operator makes that casting unnecesary:

Good point. I was kind of wondering about that. It brings up a question, though: How does inheritance play into operator overloading. Does operator overloading behave more like shadowing (hence it would be carried up the inheritance chain into derived classes, but not the other way)? Or is it more like overriding (down-casting won't prevent invocation of overriding method)?

 

[mskeel]

I don't think I quite understand...it's more like overloading. You can still cast an object to its base and use the overloaded operator you intend to use. If you don't overload the operators (all are required if you create one) then I think you will use the base class's operators. That's why you can still use == on an object you declare even though you never wrote the == operator - your using the Object Class's Equals operator.

 

[snarfblam]

Oh.. my confusion stems from the fact that I didn't realize that operator overloads were static (can you tell that I've never overloaded an operator before?). I suppose overloading would be the appropriate term.

I'm kind of weary of the fact that operator overloading can change the behavior of the == operator. In C++ to compare for equal reference, you can compare pointers or addresses, but you must dereference a pointer to use the overloaded operator. In other words, the reference itself is a different type than the class and the operators function differently on these different types, hence you are adding functionality, but not modifying it, where in C# you can introduce ambiguity since you can overload the operator that previously compared the references.

 

[mskeel]

In other words, the reference itself is a different type than the class and the operators function differently on these different types, hence you are adding functionality, but not modifying it, where in C# you can introduce ambiguity since you can overload the operator that previously compared the references.

You raise a very valid point. That has always been on of the things that has bothered my about both VB.Net and C#, the whole value vs reference types (hidden pointers). When overloading the operator you have to be sure to call the Object Class's equals operator so that you build the reference check into your equals operator. That way you get both checks for equality in your operator. But that shouldn't be too different from other times you would overload a base class implementation -- the base class will almost always be called at some point (base.Something()).

Operator overloading is quite powerful. I wonder if they put it in the new VB.Net?

 

[mskeel]

To get this back on subject of CrAzY code, here's a snippet from my personal collection. Actually, a coworker wrote this on a project he and I were working on together about 2.5 years ago, back when we were still quite new to VB and very new to .Net:

If Not DataFileNodeList Is Nothing Then
   Dim FileList As New ArrayList
   For Each child As XmlNode In DataFileNodeList
      Dim Path As String = child.Item("Full-Path").FirstChild.Value
      FileList.Add(Path)
   Next

   Dim MichaelsFaultList(FileList.Count - 1) As String
   Dim Counter As Integer
   For Each Item As String In FileList
      MichaelsFaultList(Counter) = Item
      Counter = Counter + 1
   Next
   openAndInsertFiles(MichaelsFaultList)
End If

So, openAndInsertFiles required a string array, the XML was unpacked into an arrayList for convenience, and then becuase I required a string array in openAndInsertFiles, my friend created the "MichaelsFaultList" string array and send that to me becuase he felt it was an unecesary step. sheesh.

 

[Nerseus]

Since it's off-top, I'll keep it short:

I'm kind of weary of the fact that operator overloading can change the behavior of the == operator

There's an excellent reference on the difference between ReferenceEquals(), static Equals(), instance Equals() and operator== in C# in the book Effective C# - 50 specific ways to improve your C#.

For operator== you normally only override for value types - and you should ALWAYS override it for value types, if you're going to compare your value types. You override it for performance only. For a reference type you would almost never override operator==.

-ner