Archive for April 22nd, 2011In the past couple of weeks I have been programming in .NET for the first time since 2006. My last stint was actually mostly C++-stuff in a code base based on MFC, so the .NET parts were really not that prominent, and I did not touch C# at all. This means that I was new to C# in all relevant aspects when the current project started. The project is integration work – we are embedding a thin C# client in third party software to enable integration between that software and our main product implemented in Java. Starting out, the first expression is really how similar C# and Java are. As a Java developer there are no problems getting started – mostly it’s just new APIs to learn. You will also of course have to switch IDEs – in my case from Eclipse to Visual Studio .NET 2010. Still, the main difference is the keyboard shortcuts, and I am amazed how quickly my brain can replace hardwired shortcut commands such as Ctrl+/ for comment section to Ctrl+k, Ctrl+c. Even stranger is when you go back to Eclipse and you are suddenly dumbfounded when you can’t remember the old shortcut anymore. Of course, after a while you start to notice other things – the perks, the annoyances and the little differences. I will spend the rest of this post listing some of the stuff I have noticed. Visual Studio vs Eclipse Visual Studio is more polished, feels quicker and is much more user friendly. I was surprised at this, because that was definitely not my impression five years ago. Now, Visual Studio just feels more modern. The one thing I lack is Maven, or something similar. We are two developers on our current project, and we have set up our projects a little bit differently, so we keep overwriting our project files in the SVN repository. It is annoying to have to manually update the project references after every SVN update, and I really detest having to include binaries in the SVN. Of course we could just work out a common setup, but in Eclipse with Maven this problem would not exist in the first place – dependencies would just be automagically resolved. Properties In C#, a class can have properties, which is basically variables with getters and setters. (The property concept allows for much more, but this is mostly how I have seen it used.) At times, this is really neat, but I don’t like it because it seems to promote get/set programming as opposed to Tell, Don’t Ask. Of course nobody is forcing you to use properties, but it is an easy enough trap to fall in – I feel I have already begun to overuse it. Delegates Delegates seems like a powerful thing, but I have not seen it used in the code base, which makes me kind of hesitant to try it out. The delegate concept actually promotes OOP (as opposed to e.g. properties) since it makes it possible to send a function as an argument to a method. In Java, this would be handled by declaring an interface with a single method and implementing an anonymous inner class. In comparison, the delegate concept seems much more elegant. Java apparently will get closures Any Day Now, which I really look forward to. Naming of Classes and Interfaces This really bugs me with C#. In something that must be the last remnant of the (blissfully) long dead Hungarian notation, interfaces in the .NET API are prefixed with the letter “I”. I don’t see the point of this at all – quite the contrary, it is downright harmful. Compare these two method declarations in C#:
The second example just feels cleaner. It’s just not right that you are punished aesthetically by programming to an interface. Compare with these Java declarations:
Here, the declaration using the interface is much cleaner. This might seem like a small thing, but it’s really not – the Java API is subtly guiding you into OOP, while C# is doing the opposite. Another important issue is that in the C# version the reasons for programming to an interface are not clear. It looks as if
Tags: C#, Java, OOP |