One of the great things about moving to a new language is the lack of legacy restraints. We have no ‘years of doing this way’ behind us that we have to adhere to, there’s no legacy code that we have to use specific syntax for, and there’s no concept of the right way to do things.

As we learned C# we had to lookup the way to do things, not the syntax specifically, but things like starting methods with capital letters, how to fold code so it’s readable, etc.

Here’s my look at the good, the bad, and ugly of that in the hope it helps other vb.net developers to transition successfully.

The Good.

Compilation speed. Sounds odd, but Visual Studio does seem to compile C# at a much faster pace than vb.net. We’ve not run any performance counters on it, it might just be perception, either way, it’s a positive experience.

Formatting options in the editor. While vb.net uses ‘pretty listing’, you have little control over what it does. In the C# editor, there are a lot of configuration options. For example, we chose not to have the opening { on a new line as it just takes up vertical space on the screen; maybe that’s come over from vb.net where you don’t have opening blocks, but it works for us.

Ability to have a property on a single line. While vb.net is very readable, that comes at the cost of verboseness, specifically, a simple read-only property with custom return and set parts spread out over many lines. in C#, this can all be done on a single line. It makes areas of the code that deal with multiple properties much easier to view in C#. The same principle goes for enums, where they can go on a single line, nice.

Case dependency naming. Coming from vb.net where you declare a variable called ‘TheCounter’ means intellisense will show it to you and you know that’s the one you need. As opposed to C# where there could be 27 versions of that variable all with slightly different case. I understand that this can be useful, I’ve started to use code such as ‘var imageConverter = new ImageConverter();’ instead of ‘dim myImageConverter = new ImageConverter’ and the editor does a good job of selecting the right ones where I need them, but not always, sometimes it gets confused. I’m getting used to it but it takes time.

The Bad

Okay, there’s no getting away from it, curly brackets {}. From a vb.net perspective, having the compiler understand where a code block starts is very cool. The closing of a code block by name is also very much easier to read. I can look at ‘end for’ and know exactly what and where it works, as opposed to ‘}’ – which means nothing without hovering over it of following the dotted lines up the editor.

Semi-colons, ah yes, the famous end of line (or multiple lines) character. When I started to move to C# I forgot this 90% of the time, I still forget every so often. It was nice that the vb.net compiler could work out multiple lines without the need of a continuation or termination character.

The Ugly

Empty brackets ‘()’ on calls to methods that have no parameters. I can understand why they were originally needed, maybe 20 years ago, but today I should be able to call a ‘function’ without having lots of redundant text and keystrokes reducing my productivity. For example, intVariable.ToString().Length().ToInt() – yes I know you’ve never do it that way, but I show it to represent the reduction in readability, extra typing, and pointlessness of it.

#Region. I loved this in vb.net, it was nice and discreet, sat in the margin and folded code perfectly. In C# it lives right up there, indented with your code which makes it very hard to ‘see’. In vb.net you’d simply scan down the left margin to see the folding groups, in C# it’s hidden inline with the code and impossible to spot.

Paragraph spacing is an odd one because in vb.net it was very clear where and what a method/function/structure/class was just by looking at the code. It has lines in-between and a definite start and end (probably due to the verboseness of ending blocks). But in C#, the end of a function/method just seems to die off like it couldn’t be bothered, they all end with multiple } and fade into obscureness as opposed to the bold ‘End Function’ Hi, I’m here!. I started using lots of blank lines between methods (about 5) and switched on the ruler line, but it’s never felt good, it feels contrived and a work-around. I started moving blocks of related code into new files as I’ve seen this used a lot from samples, and that makes sense now, maybe that’s the best way in the absence of #region being of real use. I’ve read lots of debate on the use of ‘smelly code’ and #region. I begrudgingly like separating out the code into files, but I have some classes where there are 15 files, some of them with a single method in because the separation into files only makes sense if you have a methodology behind it, for example, on a custom control we have files names ‘properties’ ‘instantiate’ ‘read’ ‘write’ etc. we can’t really then have a file that says ‘all the other stuff that we didn’t categorise.cs’.

None of the above

This is personal preference and has to do with all programming languages that use curly brackets and semi-colons, including C#, Swift, PowerShell, Java, etc. They just look old. ‘Swift’ took a great move and got rid of the semi-colon (good start) and when I say that and compared it to C#, C# looked old. That’s purely personal preference and maybe the option to get rid of it and the ‘()’ everywhere will save billions of keystrokes, millions of extra bytes, and give me happy hands.