Showing posts with label C#. Show all posts
Showing posts with label C#. Show all posts

Wednesday, July 11, 2007

a List vs. IList

One of the advantages of being a programming language polyglot is that you get to see the difference of how people work in all those languages. Of course it might take a while before you're comfortable enough with a language to be able to appreciate it, yet step back far enough to see the patterns of people (including yourself) using that language. But once you do, it takes your understanding of programming languages to a whole new level.

That's all very nice and abstract, but I recently encountered a very practical example of the difference between the C# collection classes and the Java collection classes. While reviewing some of the code of a new prodct, I noticed that a lot of methods in the API were accepting and returning List objects.

  • List filterInstructions(List instructions);

Now without reading further tell me, which language is this: C# or Java. Don't worry, I'll wait while you think about it...





Ok, that wasn't very nice of me. You can't really tell which language it is, since the syntax is valid in both.

But there is a huge difference in what it actually means in both languages. In C# List is a concrete implementation of the IList interface. In Java List is an interface, which is implemented by classes like LinkedList and ArrayList. Do you notice the subtle difference? In C# List is a concrete implementation, in Java it is an interface. So the above code sample in C# would accept only instances of the List class (or a subclass), while the Java implementation would accept any implementation of its List interface.

Now I don't want to start a debate on whether classes should accept or return interfaces or concrete classes. There are plenty of good discussions out there. What I want to do is show what might cause the difference in what I often see in Java code and what I see in C# code.

The example above was from a C# class in one of our products. So the developer chose to expose a concrete List implementation, instead of the IList interface. I noticed this and -coming from a Java background- wondered whether our Java developers would normally expose e.g. an ArrayList in Java. They wouldn't. They would expose the List interface instead. So I asked the C# developer why he chose to expose the concrete class, rather than the interface. He didn't have a specific reason, he just did what was easiest: expose the List class.

Keep in mind that a good developer is a lazy developer. So actually this developer was taking the right approach (be lazy) yet he got a different result than what I'm used to seeing in Java code. But then why wouldn't a Java developer expose his ArrayList, but instead choose to expose the List interface?

Well... I know one possible reason. Both of them are exposing the same thing: a list. And actually they are both saying exactly that in their contract: we're accepting and returning a list. It's just that when you literally say that in C# ("I am exposing a List") it translates into a concrete class, while if you say the same thing in Java ("I am exposing a List") it translates into an interface.

It's really all a matter of understanding how a developer thinks and how your choices in class library design influence that thinking. In this case it is very simple: Microsoft seems to put the List class first in your mind, while Sun/Netscape puts the List interface first. A small detail to many, but I found it an interesting difference between the platforms. What a difference an I makes. :-)

Saturday, July 7, 2007

Background compilation vs background unit test runner

A few months ago I posted about how to get background compilation in Visual Studio by using Resharper. It's really remarkable how background tools like these can improve your productivity. Sure, you'll have to learn to ignore the red wiggly lines until you're done typing. In that respect it is no different than the spell checking in Word or Firefox. But once you know when to check the results and when to ignore them, background compilation with "in code" feedback is a real time saver. I probably would have worn out my ctrl-shift-B combo long ago without it.


This week I noticed that even though compilation is automatic, you still have to start unit tests manually. And while they're running, you have to wait for the unit tests to complete before you can continue working on your code. And if you have a substantial set of tests, like the good test-driven developer, running them may take a few minutes. So running the tests is quite disruptive to the development process.

And as you probably know, if something breaks the flow of your development process you probably won't do it as often as might be useful. Why are continuous build systems so good? Because they work automatically when you check something into your version control system. Why is background compilation so good? Because it works automatically as you're making changes to the code.

So why can't we then have the unit tests running in the background? Sure, it'll eat up some resources. But it's not like my machine needs all its megahertz's to keep up with my typing anyway. And I can only imagine how great it would be to automatically see a purple line appear under some code I just changed that broke one of the unit tests.

Sounds like cool stuff to me. Does anyone know if this already exists?

Thursday, May 17, 2007

Resharper: C# background compilation

In a recent post Jeff Atwood complains about the lack of background compilation of C# code in the Visual Studio IDE. Coming from a Java background -where background compilation is pretty much standard in any IDE- it was indeed one of the first annoyances I noticed when I started doing C# projects. For a tool that has gone through so many iterations of improvements it is amazing how many of these annoyances are still left in Visual Studio these days.

Luckily the solution for most annoyances is easy and not even that expensive: get Resharper.


Resharper is a tool made by JetBrains that fills many of the gaps that you might find in Visual Studio. Gaps that are especially obvious if you come from a Java background and have used JetBrains' masterful Java IDE: IntelliJ IDEA.

IntelliJ IDEA is what JetBrains got famous with. And they've copied pretty much every feature over to Resharper. And then added some more.

IntelliJ IDEA is simply the most productive developer environment I have ever used, and that includes Borland's old tools that pretty much set the standard for me. Everything from simple auto-complete (like IntelliSense), smart auto-complete (which allows me to "type" complete lines of code by just pressing alt-enter a few times) and an extensive set of refactorings are all in IntelliJ IDEA by default.

Keep in mind: the version of IntelliJ I use almost daily at work is about four years old now, so probably IntelliJ IDEA is even better these days. We've just never gotten round to upgrading it. And since we're still stuck writing for Java 1.4 at work, it is not strictly needed to upgrade. But it just shows how good IntelliJ is: a four year old version of it still beats Visual Studio (at least as far as productivity is concerned) every day.