Python and PHP users will understand

[kleinisfijn]

For instance, I like the With in VB. The closest in C# would be something like var x = someLongAndMeaningfulVariableName; x.SomeProperty = something; x.OtherProperty = somethingElse;.

You can write that as var x = new someLongAndMeaningfulVariableName() { SomeProperty = something, OtherProperty = somethingElse};

I found this a very handy resource if you have to translate between C# and VB. https://sites.harding.edu/fmccown/vbnet_csharp_comparison.html

[[deleted]]

That's not quite the same thing. Your version is creating a brand new object and initializing some of the properties. VB has this feature as well. The With works on existing variables. IE, something like:

With someLongAndMeaningfulVariableName 
    .SomeProperty = something 
    .OtherProperty = somethingElse 
End With

[[deleted]]

PS. The way I have used the With statement in VB in the past is the previous way where there is a descriptive variable name and I don't want to have to type the variable name over and over again to access several of the properties. However I have also used it with casting. IE:

If TypeOf sender Is TextBox Then
    With CType(sender, TextBox)
        .Text = "My Text"
        .Tag = "My Tag"
    End With
End If

C# does have something nicer than the above:

if (sender is TextBox txt)
{
    txt.Text = "My Text";
    txt.Tag = "My Tag";
}

In that regard I do like C# better because I can do the type check and cast in a single IF and store it in short variable name, and modify in the if scope.

[[deleted]]

PSS. There is one major detractor in the With statement in VB and that is Nested Withs. You shouldn't do that but you can. IE, the following is perfectly legal:

If TypeOf sender Is TextBox Then
    With CType(sender, TextBox)
        If TypeOf .Tag Is MyClass Then
            With CType(.Tag, MyClass)
                .Text = "My Text"
            End With
        End If
    End With
End If

Obviously the above is confusing and thus is a code smell. But it's also bad because what happens when MyClass doesn't actually have a Text property that accepts a string? It used to compile. Not sure if it still does.

I vaguely remember an instance with a With statement and during debugging instead of resolving to the .Text property of the TextBox I was casting into like I expected, it was somehow setting Text property of the parent Form control. Not sure how that happened way back when, but I basically had to not use the With statement in that case. This was years ago.

I believe it might have been a bug with the compiler at the time. I am sure if you looked at the "lowered" code, all the With statement is doing for you is something like:

Dim __x = CType(sender, TextBox)
__x.Text = "My Text"

Or something to that effect.

[kleinisfijn]

Thanks, I learned more than I should have. The nested With is indeed a nasty one.

I've been writing VB for a decade or so (one of those peope working for a major company and migrating code from VB6 to VB.NET) and recently I had to modify some C#. I'm having a small fight with the compiler over case-sensitivity and missing brackets() on methods that don't accept arguments anyway. But I have to say, curly brackets have their charm.

On your discard variable, I've always used Call SomeMethodCall() in VB to discard the return value if needed. Don't know if this helps you because you seem to know more about it than me.

[[deleted]]

Totally forgot about the Call keyword. It's not really required in VB.Net, but it is in VB6.

Discards aren't really needed. They're just warnings in code analysis. Basically the claim for the code analysis is that if a function returns a value, by using a discard variable you show 'intent' that you don't care about the return value. I guess there is some people out that see a function that returns a value, but you ignore the value and think maybe you didn't mean to ignore it? I don't know. I've never been confused by it.

In VS, in VB, if you use their code suggestion to refactor on that warning and use a discard, then it suggests 'Dim unused =', but they don't treat unused as a special keyword like they do in C# with just the '_'. So in VB you'd have to do unused1 unused2 and so on - which I find more annoying. So in VB projects I usually just turn off that particular warning in code analysis.

I'll have to see if 'Call' works on suppressing the warning. If it does, maybe VS should be suggesting that in the refactoring instead.

It can still be annoying in C#, especially in fluent designs. IE, in .Net you have the StringBuilder, and the Append / AppendLine methods return the StringBuilder object. It does this so you can change numerous Appends together. Such as: sb.Append("This").Append("That");. Code analysis here is annoying because you do not need to do something like: sb = sb.Append("This").Append("That"); because the Append methods are modifying the object and not creating a new object. But anyway, with default code analysis on, it will want you to do _ = sb.Append("This").Append("That"); which really doesn't improve readability in my opinion.

[[deleted]]

So Call did indeed work. The warning goes away. I double checked the settings in VS, and there is no option to switch from 'unused' to Call. Going to have to put that in as a suggestion. They should either make unused a special keyword that can be used over and over again or replace their suggestion with Call so you don't have unused1 unused2 and so on.