codeformatter
codeformatter copied to clipboard
dotnet
Add VB.NET Styling please
Hi guys,
I'd love to see VB.NET styling added here, we have a lot of projects in VB (unfortunatly) .
Thanks :-)
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.
Couple of things I can think of
-
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 = exbecomes
System.Threading.Thread.Sleep(Sleep)AttemptFailure = TrueTryAttempt += 1AttemptEX = ex -
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"
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.
@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 constructLBlocksome codeEnd 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
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.
@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.
@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.
@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.
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
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" < [email protected]>:
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.