Funny code

snarfblam

Mega-Ultra Chicken
Joined
Jun 10, 2003
Messages
1,832
Location
USA
User Rank
*Expert*
While translating some of my old VB to C#, I found this amusing line of code in a class I wrote a while ago.
[VB]
If Not Me Is Nothing Then
Save(Medium.GetKey)
End If
[/code]
I couldnt 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 dont program for a living.

Anyone else?
 
why would me ever BE nothing?

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

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

Talk about confusing...
 
I like it :)

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

-ner
 
Makes you wonder why they didnt add a Something keyword to simplify the syntax...
Code:
If Me Is Something Then
    Save(Medium.GetKey)
End If
 
Nerseus said:
I like it :)

I wonder if anyone has some code like:

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

-ner
Actually, I have something similar, but this code actually does something more than confirm its existence.
C#:
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.
 
Last edited by a moderator:
I always thought the use of a g$ var in qbasic was funny. But then again, I have no life.
 
LoL WTFuk
I cant stand VB or VB.NET It allows to much non OO style programming!!!!!!!!!!!!!!!!!
 
kurf said:
LoL WTFuk
I cant 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.
 
kurf said:
LoL WTFuk
I cant 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... Ive found that you have to go out of your way pretty hard to NOT be OO.
 
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!!!!
 
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#:
C#:
// Before it occured to me to use the != operator for reference types
if(!(MyObject == e.Sender)) {
    // Do things and junk
}
 
marble_eater said:
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 youve 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:

C#:
if ((object)mySuperObject == null)
{ 
   /* Do Something, probably return */
}
Code:
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).
 
Im just as intruiged as to how you knew it was patented as to how it became patented. I must admit that as Im used to c# I sometimes get caught out by the use of the Is operator. Im 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.
 
mskeel said:
You do have to be careful, though. If youve 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 wont prevent invocation of overriding method)?
 
I dont think I quite understand...its more like overloading. You can still cast an object to its base and use the overloaded operator you intend to use. If you dont overload the operators (all are required if you create one) then I think you will use the base classs operators. Thats why you can still use == on an object you declare even though you never wrote the == operator - your using the Object Classs Equals operator.
 
Oh.. my confusion stems from the fact that I didnt realize that operator overloads were static (can you tell that Ive never overloaded an operator before?). I suppose overloading would be the appropriate term.

Im 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.
 
marble_eater said:
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 Classs 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 shouldnt 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?
 
To get this back on subject of CrAzY code, heres 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:
Code:
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.
 
Last edited by a moderator:
Since its off-top, Ill keep it short:
Im kind of weary of the fact that operator overloading can change the behavior of the == operator

Theres 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 youre going to compare your value types. You override it for performance only. For a reference type you would almost never override operator==.

-ner
 
Back
Top