Add VB.NET Styling please

[Kraeven]

Hi guys,

I'd love to see VB.NET styling added here, we have a lot of projects in VB (unfortunatly) .

Thanks :-)

[jmarolf]

What would be some example styling rules for VB? C# has a much broader range of acceptable formats, whereas VB has much of its rules about style built into the language itself.

[Salz150]

Couple of things I can think of

1. Use only one statement per line. Don't use the Visual Basic line separator character (:).

   For example
   System.Threading.Thread.Sleep(Sleep) : AttemptFailure = True : TryAttempt += 1 : AttemptEX = ex

   becomes

   System.Threading.Thread.Sleep(Sleep)
AttemptFailure = True
TryAttempt += 1
AttemptEX = ex

2. Comments on seperate lines.

   For example

   Dim foo As Integer ' foo is an integer.

   becomes

   ' foo is an integer.
Dim foo As Integer

There are more here: "Visual Basic Coding Conventions"

[jaredpar]

I think for actual code formatting we should prefer the behavior of the pretty lister. This is the standard by which the over whelming majority of VB developers write their code.

[AdamSpeight2008]

@Salz150 Enforcing comments being on a newline.

    Function Foo(arg1 As Integer, ' a
                 arg2 As Integer  ' b
                 ) As Integer
        Return 0
    End Function

Is valid in the VS2015 CTP5, which allows comments after implicit line continuations.

It can also be used in LINQ Query style.

Dim addrs = From i In invites     ' go through list
            Let addr = Lookup(i)  ' look it up
            Select i,addr

Could potentially change the meaning of the code, or be syntax errors..

---

@jaredpar
Maybe the Style Guidance should be updated (pre Roslyn). Since now the formatter can access more knowledge of what the source text actual represents.
The aims should;-

• less visual clutter whilst preserving the meaning.
• Read-ability
• Skim-ability
  So you can quickly look through / at the code, which makes it easier to spot patterns (which the brain is very good at). Those patterns could then be a target of refactoring.

Don't bring the C-Style of code to VB.net,

• Some ain't appropriate.
• It can make the code less readable. or ugly.
• 4 Space indentation? It needed in C-Style so you can spot the enclosing braces.
  2 spaces is good enough in VB.net, because if verbosity of character of keyword and constructs. Block constructL Block some code End Block
• Well formatted VB.net code can look as good as C-Style code when it's well.

Prefer Single Line for Simple code

We don't always need multiple lines to express our intent.

If   ... Then ....
'<---------------| ( <= 80c )

Prefer simplest IF form. Especial if the total width of the single line version is <= 80

If   ... Then ....

Rather that the 3 line version.

If ... Then
 ...
End If

Rationale: Guard Statements

Simple Case-Clauses

Select Case value
  Case Is < 0 : Throw
  Case 0      : Return "Zero"
  Case 1      : Return "One"
  Case 2      : Return "Two"
  Case Else
End Select

---

Break Method Parmeters at 80c limit

Method should be broken at the 80c, then placed on then following.

Function Foo( argument0 As SomeReallyLongNamespaceAndClassName, argum1 As SomeReallyLongNamespaceAndClassName, arg2 As SomeReallyLongNamespaceAndClassName) As SomeReallyLongNamespaceAndClassName

eg

Function Foo( argument0 As SomeReallyLongNamespaceAndClassName,
              argum1    As SomeReallyLongNamespaceAndClassName,
              arg2      As SomeReallyLongNamespaceAndClassName
            ) As SomeReallyLongNamespaceAndClassName

---

Align Assignment

source

        Friend Const FULLWIDTH_LEFT_PARENTHESIS_STRING As String = FULLWIDTH_LEFT_PARENTHESIS
        Friend Const FULLWIDTH_RIGHT_PARENTHESIS_STRING As String = ChrW(fullwidth + AscW(")"c))
        Friend Const FULLWIDTH_LEFT_CURLY_BRACKET_STRING As String = FULLWIDTH_LEFT_CURLY_BRACKET
        Friend Const FULLWIDTH_RIGHT_CURLY_BRACKET_STRING As String = FULLWIDTH_RIGHT_CURLY_BRACKET
        Friend Const FULLWIDTH_FULL_STOP_STRING As String = FULLWIDTH_FULL_STOP
        Friend Const FULLWIDTH_COMMA_STRING As String = FULLWIDTH_COMMA
        Friend Const FULLWIDTH_EQUALS_SIGN_STRING As String = FULLWIDTH_EQUALS_SIGN
        Friend Const FULLWIDTH_PLUS_SIGN_STRING As String = FULLWIDTH_PLUS_SIGN
        Friend Const FULLWIDTH_HYPHEN_MINUS_STRING As String = FULLWIDTH_HYPHEN_MINUS
        Friend Const FULLWIDTH_ASTERISK_STRING As String = ChrW(fullwidth + AscW("*"c))
        Friend Const FULLWIDTH_SOLIDUS_STRING As String = FULLWIDTH_SOLIDUS
        Friend Const FULLWIDTH_REVERSE_SOLIDUS_STRING As String = ChrW(fullwidth + AscW("\"c))
        Friend Const FULLWIDTH_COLON_STRING As String = FULLWIDTH_COLON
        Friend Const FULLWIDTH_CIRCUMFLEX_ACCENT_STRING As String = ChrW(fullwidth + AscW("^"c))
        Friend Const FULLWIDTH_AMPERSAND_STRING As String = FULLWIDTH_AMPERSAND
        Friend Const FULLWIDTH_NUMBER_SIGN_STRING As String = FULLWIDTH_NUMBER_SIGN
        Friend Const FULLWIDTH_EXCLAMATION_MARK_STRING As String = ChrW(fullwidth + AscW("!"c))
        Friend Const FULLWIDTH_QUESTION_MARK_STRING As String = FULLWIDTH_QUESTION_MARK
        Friend Const FULLWIDTH_COMMERCIAL_AT_STRING As String = ChrW(fullwidth + AscW("@"c))
        Friend Const FULLWIDTH_LESS_THAN_SIGN_STRING As String = FULLWIDTH_LESS_THAN_SIGN
        Friend Const FULLWIDTH_GREATER_THAN_SIGN_STRING As String = FULLWIDTH_GREATER_THAN_SIGN

                Friend Const LEFT_PARENTHESIS$    = FULLWIDTH.LEFT_PARENTHESIS
                Friend Const RIGHT_PARENTHESIS$   = ChrW(_fullwidth + AscW(")"c))
                Friend Const LEFT_CURLY_BRACKET$  = FULLWIDTH.LEFT_CURLY_BRACKET
                Friend Const RIGHT_CURLY_BRACKET$ = FULLWIDTH.RIGHT_CURLY_BRACKET
                Friend Const FULL_STOP$           = FULLWIDTH.FULL_STOP
                Friend Const COMMA$               = FULLWIDTH.COMMA
                Friend Const EQUALS_SIGN$         = FULLWIDTH.EQUALS_SIGN
                Friend Const PLUS_SIGN$           = FULLWIDTH.PLUS_SIGN
                Friend Const HYPHEN_MINUS$        = FULLWIDTH.HYPHEN_MINUS
                Friend Const ASTERISK$            = ChrW(_fullwidth + AscW("*"c))
                Friend Const SOLIDUS$             = FULLWIDTH.SOLIDUS
                Friend Const REVERSE_SOLIDUS$     = ChrW(_fullwidth + AscW("\"c))
                Friend Const COLON$               = FULLWIDTH.COLON
                Friend Const CIRCUMFLEX_ACCENT$   = ChrW(_fullwidth + AscW("^"c))
                Friend Const AMPERSAND$           = FULLWIDTH.AMPERSAND
                Friend Const NUMBER_SIGN$         = FULLWIDTH.NUMBER_SIGN
                Friend Const EXCLAMATION_MARK$    = ChrW(_fullwidth + AscW("!"c))
                Friend Const QUESTION_MARK$       = FULLWIDTH.QUESTION_MARK
                Friend Const COMMERCIAL_AT$       = ChrW(_fullwidth + AscW("@"c))
                Friend Const LESS_THAN_SIGN$      = FULLWIDTH.LESS_THAN_SIGN
                Friend Const GREATER_THAN_SIGN$   = FULLWIDTH.GREATER_THAN_SIGN

note: My personal version of Roslyn is structured slight differently, but it's a lot easier to glance over.

[AdamSpeight2008]

@jaredpar
This is the standard by which the over whelming majority of VB developers write their code.

Nope, That's the default setting in VS and programmers are inherently lazy.

[jaredpar]

@AdamSpeight2008

So because Visual Studio.chose defaults that appeal to a large number of VB developers that makes them lazy? Sorry, that doesn't follow. Additionally you didn't address the original point I was making; the pretty lister represents the style used by the majority of VB code.

Choosing a style should not be an argument about personal preferences. It should instead be a discussion about making consistent and easily enforcable decisions. Given that the pretty lister already formats most VB code out there, deviating from it would go against the easy enforcement goal.

It would also increase the size of the change necessary to move existing code to the new model. One of the nice items about the code formatter today is that it's actually not that disruptive for C# code. With the exception of renaming private fields and adding explicit modifiers, items which would affect Visual Basic as well, it had little affect on the structure of programs.

I'm not saying we should be bound to the pretty lister strictly. But we should only deviate from it when there is a clear and demonstrable readability win associated with it. I haven't seen any such argument yet.

[Salz150]

@AdamSpeight2008 good point about inline comments - I didn't think that through.

@jaredpar good point about the : - I guess it's in there for a reason. :)

I like the ideas about aligning assignment operators and breaking method parameters at 80c.

[AnthonyDGreen]

Hey @Kraeven,

Thanks for making this request. We've started work on porting some of the shared rules to VB. Expect to hear more from us on VB style in the coming days.

RE: Kraeven said:

...we have a lot of projects in VB (unfortunat[e]ly)

Our open source community is young yet and I think this raises a good opportunity to talk about how we all engage each other here.

First and foremost, the .NET Foundation is and needs to remain a place where all .NET developers feel welcome to participate. That means C# developers, F# developers, and VB developers too. Of course we all have preferences, but, we absolutely do not want to create a culture here where developers feel a need when jumping into conversation to apologize for what languages or technologies they're using or not using, or to make disparaging remarks about Java, or JavaScript, or VB, or C++, or VB6, or anything else to establish any kind of "street cred". You shouldn't feel that when you come here and you have VB.NET code you need to drop a casual insult on the product so that other developers will respect you. There should be an expectation here that you and your inquiries and opinions, provided they are on topic and given in a civil manner are respected and responded to in kind as a matter of course. Remarks like this are at worst inflammatory and at best distracting and send the message to people who use VB (like myself) that the .NET Foundation open source community is hostile and not a place for them and it sends the message to people who don't use VB that they can get cool points here by dumping on it. Neither of those are the right messages to send.

Secondly, it is important to keep in mind that this is a community where developers can engage members of the Microsoft product teams who work directly on a number of products, including VB and you never know when someone who is or has worked on a product, such as VB, may be listening or may even be the very person you're soliciting help from or making a suggestion to. For example, both Jared and I are members of the Visual Basic Language Design team. I've been a huge VB fan and advocate personally and professionally for years (even before joining Microsoft), have worked on the VB compiler as part of the "Roslyn" project for five years, and coincidentally own figuring out whether and how to extend the VB styling guidelines already provided by the formatter/pretty-lister. Jared has owned or worked in parts of the VB compiler, IDE, and debugger for many more years than that. We and dozens of others have worked very hard and very passionately on VB for years and we take an incredible amount of pride in that work and VB and its community just as much as we do in C# and F# and those communities. And by "take pride in" I mean we're fans who have VB T-shirts, and VB coffee mugs, and VB banners in the hallways who use VB daily and delight in the opportunity to do so (and to be clear, most of us, particularly on the Managed Languages team work on and in more than one language). When you flippantly insult a product that dozens of people have poured a lot of love into in a forum that's kept vibrant in part by the dialog between consumers and those product owners you run the risk of creating either disengaged or defensive product group team members, neither of which contributes positively to the health of the .NET open source community.

In summary, let's keep this place fun, positive, and welcoming for everyone invested in .NET and its future and leave the language bashing and all the other stuff outside, ok?

Warmest regards,

Anthony D. Green
Program Manager
Visual Basic, C#, and F# Languages Team

[Kraeven]

Oh sorry, I really didn't 't mean it that way. I love VB.. Clear and very
readable.. It's a pity that it's not so popular, most tools and plugins are
focused on other languages, people tend to dismiss the power that lies
underneath just because C# has the masses acceptance. Thanks for answering
my request, I really appreciate it.

Got to get me such a T-shirt.. :-)

Keep up the good work!

Kraeven

Op 16 feb. 2015 12:26 PM schreef "Anthony D. Green" <
notifications@github.com>:

Hey @Kraeven,

Thanks for making this request. We've started work on porting some of the
shared rules to VB. Expect to hear more from us on VB style in the coming
days.

RE: Kraeven said:

...we have a lot of projects in VB (unfortunat[e]ly)

Our open source community is young yet and I think this raises a good
opportunity to talk about how we all engage each other here.

First and foremost, the .NET Foundation is and needs to remain a place
where all .NET developers feel welcome to participate. That means C#
developers, F# developers, and VB developers too. Of course we all have
preferences, but, we absolutely do not want to create a culture here where
developers feel a need when jumping into conversation to apologize for what
languages or technologies they're using or not using, or to make
disparaging remarks about Java, or JavaScript, or VB, or C++, or VB6, or
anything else to establish any kind of "street cred". You shouldn't feel
that when you come here and you have VB.NET code you need to drop a casual
insult on the product so that other developers will respect you. There
should be an expectation here that you and your inquiries and opinions,
provided they are on topic and given in a civil manner are respected and
responded to in kind as a matter of course. Remarks like this are at worst
inflammatory and at best distracting a nd send the message to people who
use VB (like myself) that the .NET Foundation open source community is
hostile and not a place for them and it sends the message to people who
don't use VB that they can get cool points here by dumping on it. Neither
of those are the right messages to send.

Secondly, it is important to keep in mind that this is a community where
developers can engage members of the Microsoft product teams who work
directly on a number of products, including VB and you never know when
someone who is or has worked on a product, such as VB, may be listening or
may even be the very person you're soliciting help from or making a
suggestion to. For example, both Jared and I are members of the Visual
Basic Language Design team. I've been a huge VB fan and advocate personally
and professionally for years (even before joining Microsoft), have worked
on the VB compiler as part of the "Roslyn" project for five years, and
coincidentally own figuring out whether and how to extend the VB styling
guidelines already provided by the formatter/pretty-lister. Jared has owned
or worked in parts of the VB compiler, IDE, and debugger for many more
years than that. We and dozens of others have worked very hard and very
passionately on VB for years and we take an incredible amount of pride in
that work and VB and its community just as much as we do in C# and F# and
those communities. And by "take pride in" I mean we're fans who have VB
T-shirts, and VB coffee mugs, and VB banners in the hallways who use VB
daily and delight in the opportunity to do so (and to be clear, most of us,
particularly on the Managed Languages team work on and in more than one
language). When you flippantly insult a product that dozens of people have
poured a lot of love into in a forum that's kept vibrant in part by the
dialog between consumers and those product owners you run the risk of
creating either disengaged or defensive product group team members, neither
of which contributes positively to the health of the .NET open source
community.

In summary, let's keep this place fun, positive, and welcoming for
everyone invested in .NET and its future and leave the language bashing and
all the other stuff outside, ok?

Warmest regards,

Anthony D. Green
Program Manager
Visual Basic, C#, and F# Languages Team

—
Reply to this email directly or view it on GitHub.