Three things C# only developers might not know

Justin James highlights the important things developers might be missing out on if the only programming language they know is C#.

During a recent discussion with a friend, I realized there is an entire generation of developers who have been raised exclusively on C# with perhaps some Java or PHP in college as well. I like C#, and for the work I do it's my only real option other than VB.NET, but the idea of having never been exposed to any other programming language is a little disturbing. Here's a list of three things you might not know anything about if you've been raised on C# (or .NET in general). I also explain why you might want to learn these three things, and I offer advice on how to learn them.

1: Macro/scripting style

Writing code to be used for macros or scripts is an entirely different world from application programming. You can use C# for this task (particularly via PowerShell), but it is a pretty uncommon thing for .NET developers to do. This kind of programming is useful for automating repetitive tasks, especially those that are error prone. While it is usually associated with our systems administration friends, it also comes up when working with a variety of applications that support macros, such as Office and various graphics applications.

Learning to write scripts can save you a lot of time in the long run and make you more productive in a number of scenarios. It can also help you lend a hand to the administration staff. As a .NET developer, learning PowerShell is a great first step to getting a handle on this kind of development.

Related resources: 10 fundamental concepts for PowerShell scripting and Basic Windows PowerShell commands you should already know.

2: Resource management

In the world of .NET, automatic memory allocation and the garbage collector do a really good job at making sure that you don't need to think too hard about memory. Along the same lines, things like file handles and database connections often get closed down when they are garbage collected. However, "not needing to think too hard" and "not needing to think about it at all" are different.

Many .NET developers pick up some bad habits that are free of consequence in low usage scenarios, but are deadly to performance and system stability when put under load. For example, a lot of developers don't bother closing open resources (file handles, database connections, etc.) and just let those objects fall out of scope. This will work (the garbage collector eventually clears it out and the finalizer for things tends to close them too), but it is a really bad idea. Instead, you should become more conscious of this. If a class makes use of a resource, look for a "Close" method and make sure to call it when you are done with that resource. Also look for the "Dispose" method, which is used to discard resources safely. Beyond that, you should ensure that objects live at the most restricted scope that still makes sense to ensure they don't linger in memory any longer than necessary.

3: Interface with the Win32 API (and COM)

The .NET Framework does a really great job at taking the overwhelming majority of the Win32 API that we would need to work with on a regular basis and presenting it to us in a tidy package. But every once in a blue moon, you discover there's something in that API or perhaps a COM component that you absolutely need to get to. This is a great time to get to learn about P/Invoke. It will only take several minutes to learn what you need to know to be able to use it in the future.