What statements do you not write in vb.net because they are difficult to scan for meaning? And what do you write instead?

This should be a community wiki question.

I've had to work with a lot of vb.net lately, and recently created the following expression.

If If(report.IsPublicReport, False) Then Return True

Now, this is a simple coalesce inside of an if statement, nothing to be scared of. However, when I was scanning the method look开发者_开发问答ing for an error I had made, this line would constantly stop me dead in my tracks. I just couldn't scan it. Every time I had to stop and break it down manually in my head. Largely because I had to stop and figure out what each If was actually doing in the expression.

I have since rewritten the line as

If report.IsPublicReport.GetValueOrDefault() Then Return True

While more verbose, I am finding that this disrupts my train of thought less as I am scanning the code.

This got me thinking,

1. Is this something other more experienced VB.net developers are running into?
2. Are there any other types of expressions that are largely avoided, or at least not favored?
3. Am I just whining about nothing?

As long as you are uncomfortable with VB.NET syntax, I would strongly recommend you use Option Strict On so you catch mistakes like these quicker. The best way is by changing it globally so it is always on by default. Tools + Options, Projects and Solutions, VB Defaults, change Option Strict to "On".

What you're describing is something Scott Hanselman (and probably others) call "Code smell".

It's basically the idea that when you look at a piece of code and something doesn't seem "right" about it. This is not a capability that developers just "have". It's something you develop over time as you read and write more and more code.

It's not just VB either, you'll see plenty of idiomatic constructs in every language that will (or should) make you pause and question what you're looking at.

That Double IF would definitely do it for me

In Vb.NET you can write:

row!FirstName = "Test"

instead of

row("FirstName") = "Test"

A while ago I used to write row!FirstName (you can do that with every item in a collection that can be accessed by a string parameter) because I thought that was a good idea because it looks more statically typed (like person.FirstName as a property) and is shorter.

However I realized that this is not a good idea because after changing "FirstName" to "Name" i often looked for String in the current file which are highlited in Visual Studio (the object!param syntax is not). Which makes finding them harder.

You can write

Private Sub Form1_Load() Handles MyBase.Load
End Sub

instead of

Private Sub Form1_Load(ByVal sender As System.Object, _
                       ByVal e As System.EventArgs) Handles MyBase.Load
End Sub

which is fine if you don't need sender or e (I suppose it is just some compiler magic that adds the signature itself) but I refuse to use the shorter way, cause you don't recognize it as an eventhandler at first sight.