The Coding Monkey

Wednesday, June 22, 2005

Rest In Peace Jack

A man whose name you probably never knew died 2 days ago. A man who has influenced your life more than you think about day to day has passed. Jack Kilby, the inventor of the integrated circuit, died at age 81 after a brief fight with cancer. He invented the integrated circuit instead of going on vacation while working for Texas Instruments... can you imagine a world where he did go on vacation? I know my life wouldn't be the same. You will be missed, and your contribution not forgotten.

Friday, June 17, 2005

Anders Hejlsberg on C#... Again

InfoWorld has an interview with Anders Hejlsberg from Microsoft TechEd 2005 in Orlando. (H/T to Eric Gunnerson). It's the standard Anders interview. Anders has been with Microsoft for about 8 years now (before that he was with Borland where he architected Delphi). He's been the man with the plan on C# and .NET for about 5 years now. All his interviews are the same, and it kinda grinds on me, because this guy is amazing, and I wish people interviewing him would branch out some more.

  • So what is C#... or sometimes... why do we need C# over C ?
  • How does it compare to Java? Why nobody asks how it compares to Delphi I don't know, because there are a lot of similarities (duh).
  • How do you feel about open source movements?
  • What's your feelings about Microsoft? He works for them... what do you think he's going to say?
They talked a little bit about C-Omega which is cool, but even then it was just boilerplate stuff. It's a nice interview, but come one... lets get some more meat to it.

Thursday, June 09, 2005

Making Yourself Laugh in Code

Here is a comment I left in some code I wrote a couple months ago:

' If you can understand this code... then I congradulate you. See me for a cookie.

I'm not going to publish the code, as it wouldn't make sense out of context... but let's just say I had Hashtables containing Hashtables containing ArrayLists. I'm not saying it was the smartest idea, but it worked.

Anyway, I had to make a change to this code today, saw the comment, and had to laugh at myself.

Wednesday, June 08, 2005

I Hate VB.NET!

Those who know me know that I hate Visual Basic .NET. This is not a passing hatred mind you... it's a pretty strong one. Unfortunately my current client is a VB house, so I have to use it every day. There are oh so many things I dislike about it, which I'm not going to recount all at once here. However, there is one problem with it that I want to point out right now, only because it led me to needlessly debug new code of mine for about 30 minutes.

No Warnings! Specifically, it doesn't warn you if all your code execution paths don't return a value for a Function. This in my mind is a very basic warning that should be included (C# does). I'll provide an example:

Public Function GetValue() as Object
   Dim obj as Object
   ' Do a bunch of complicated things to assign obj here

   ' Should have Return obj here
End Function

Public Sub DoSomething()
   Dim obj as Object = GetValue()
   If ( obj Is Nothing ) Then
      ' Ooops... Will always get here!
   Else
      ' Will Never Get Here
   End If
End Sub

Now then... I understand it's a bit more complicated because you can also use the function name itself as a variable and it will create an implied Return call with it... but I don't know how many times this has screwed me up in the past. Add a warning if you don't ever assign to the Function name, or add a Return statement!

Tuesday, June 07, 2005

@this and that

Chris Sells points writes about a piece of C# code that freaked him out:

class Class1 {
   static void Foo(object @this) {
      Console.WriteLine(@this);
   }

   static void Main(string[] args) {
      Foo("hi");
   }
}

In case you don't quite see it... a keyword (this) is being used as a variable to represent something other than the current object. You can do this because placing the @ before a variable tells the compiler to ignore it as a keyword. It's kind of cool, but also confusing I think. VB has a similar ability if you wrap the variable in square brackets (for instance you can name something [Me]).

I knew about the square brackets in VB, but only thought an @ in C# could be used in front of a literal string. You learn something new every day.

What Does That Mean?

I'm looking over some code that I wrote just prior to going on vacation, and have been forced to say to myself "What does that mean?" I have variables that I'm not sure make sense in context, and I'm not quite sure exactly what they represent despite the fact that I added comments after their declaration. Even after I go over more of the code further down, I'm not quite sure it's right, even though it seems to be working. Never before have I been baffled by my own code so soon after writing it. This process generally takes several months to occur, not two weeks. I guess I was already on vacation before I even left.

Friday, June 03, 2005

I'm Not Trying to Be a Jerk

Honestly... I'm really not... though it may seem that way to some. One of my projects is in defect fixing mode. That of course means we get to wade through tester's descriptions of problems, and figure out what's causing them... or sometimes figure out if there is a problem at all. I'm a stickler for reproduction steps. Some may say I'm a jerk about it. If I don't see real steps to reproduce a defect, with example files that demostrate it where appropriate... I immediately reply asking for them. I'm not being a jerk... it's just experience.

This morning was a great example. I get a defect saying that every file that has a *blank* causes a problem when he does *blank*. I don't bother to check... I immediately respond with "Can you please provide an example file?" Of course the tester doesn't send me the file that caused the problem for him... he sends a list of files that have *blank* criteria in it that he says causes the problem. Of course there was the indignant tone in his email saying it's so easy to reproduce, try any one of these hundred. Fine.. that's not what I asked for, but I'll go through your list. I went through the first 6 in the list and couldn't reproduce the defect. I reply back. "Ummm... try the files that also have *blank*." Of course he still didn't send me the actual file that had caused him the problem. Fine. I go through the first one and still couldn't reproduce it. I was going to respond back after that one... but for grins I tried one more on the list and finally got the defect to reproduce.

As it turns out, the defect only reproduced under very specific circumstances... contrary to the original defect which made it sound huge, broad, and awful. It was a simple fix, but took 10 times longer to find simply because he never gave steps to reproduce. That's why I'm picky. Had he given me the actual file that he used to cause the problem, I would have been able to turn around that defect in 5 minutes. Sometimes testers just piss me off.

Thursday, June 02, 2005

I'm Not Ready to be a Parent

My current role at my current client has me doing a lot of explaining, designing, some teaching, and coding. These things I don't mind. What I'm not prepared to do is be a parent. The last two days since I've come back from vacation, I've felt like a parent. Allow me to explain. One of the projects that I'm working on is headed by a female technical lead, where I'm doing a lot of the design work while she does a lot of the overall technical leadership. I have absolutely no problem with this as she's very skilled and easy to work for. However, one of our other team members (who is older than both her and I) is acting like a little child.

He had a relatively simple, yet very important assignment to complete. He was having issues understanding it, so he came to my cube asking for me to explain it to him. He acted like he had a blank slate. I explained it to him... several times. He came away probably understanding it. I later talked to my technical lead only to find out that he had earlier done the exact same thing to her. It was like a kid who asks mommy for something, doesn't like the answer, so he goes and asks daddy. And when he doesn't get the answer he likes, he acts spoiled. It's driving me insane. Does he think that the two of us don't talk to each other?

Now today he's had more issues and pulled the same stunt. The worst part is that I'm depending on him to complete his piece so that I can complete mine... so I'll end up being screwed by the deadline as he fitters away. I'd say that this kid is driving me crazy... but he's probably 15 years my senior. How he's survived this long I don't know. I want to ground him.

In Defense of Hungarian Notation

Joel on Software has an excellent article defending Hungarian Notation, which I highly recommend. It's an excellent article which gives examples of how Hungarian is still useful today. I'm a firm believer in Hungarian Notation, and still use it to this day (properly I might add) despite the evil looks from coworkers. The problem with Hungarian was that it was bastardized over the years. When it was originally invented by Charles Simonyi at the Microsoft Apps team (think Word and Excel), it was used to differentiate variables of the same type, that had radically different meanings. For instance, two variables might represent coordinates with DWORDs, but one might be relative to the screen, and one might be relative to the page. Assigning directly between the two would cause an error, but would be syntactically correct:

DWORD xwCell;   // Cell location relative to Window
DWORD xlCell;   // Cell location relative to Layout

// ... Later on

xwCell = xlCell;             // Logic Error
xwCell = XwFromXl(xlCell);   // This is Ok, we converted.

Somehow (and Joel explains this), Hungarian got bastardized so that the prefix was only used to denote the variables physical type. So you would get code that looked like this instead:

DWORD dwCell;    // Cell location relative to Window
DWORD dwCell2;   // Cell location relative to Layout

// ... Later on ... imagine a couple screens away

dwCell = dwCell2;   // Logic Error... but would you know it?

As you can see... the Hungarian that eventually took hold has much less utility. Sure it's nice to know that a variable is a DWORD, but that doesn't prevent the logic error. Maybe it's the fact that I'm a huge fan of code reviews that makes me like Hungarian. I actually print out code and go over it with a pen and highlighter. I write notes, I ask questions... and having conventions that make these errors pop out at you help more than you can know.