Power10: Reduce verbosity through #light

[This post is part of a series, “wish-list for future versions of VB“]


IDEA: Add a #light directive, like F#, to reduce VB’s verbosity. We already eliminated the dreaded “_” to make VB syntax look cleaner. We could also use layout as in Python and F#’s “light syntax” to be able to omit noise words like End Function, End Sub, End If, End Class, End Module — they don’t have any significance, especially since the IDE is hardcore about introducing intendation.

Module Module1

    Sub Main()

        Dim s = Console.ReadLine()

        If s = “” Then

            Console.WriteLine(“you pressed enter”)




    Sub f(ByVal s As String)

        Console.WriteLine(“you wrote “ & s)


Provisional evaluation from VB team: A new syntax for the language would be a MAJOR upheaval. In this case we don’t think it brings enough benefit. In any case, we think that the new WPF-based VS2010 editor will be capable of achieving the same effect through plugins.

Comments (9)

  1. Dzonny says:

    This idea is IMO to crazy. Editor is already adding all the End … stuff for us so why care about one spared line in each construct.

    There are some places to reduce verbosity (like optional parameters) but making End completely optional – that’s not for me. Some my colleague with different tabbing setup of VS may come and completely destroy the code. And posting such code to some HTML-based forums can be real pain.

    Possible places to reduce verbosity IMO:

    • Sub ASub(ByVal a%, ByVal b% = 10) ‘b – optional

    • Sub ASub(ByVal a$, Optional ByVal b As Object) ‘b – default is Nothing

    • Throw InvalidOperationException("This should never happen") ‘New ommited

    • ‘Collection/dictionary initializers as you have suggested in your other post

    • ‘Following can be extended to custom events

       Property AProperty As Long


               Return _aProperty

           Set ‘End Get – optional; (ByVal Value As Long) – optional (it already is but editor enforces it)

               _aProperty = value

       End Property ‘End set – optional

    • ‘GetType compare this

     Public Sub AcceptsType(ByVal t As Type)

     End Sub



     ‘VB 11


    • Make Implements optional for methods/properties/events when implementing interfaces (as in C#)

    • Infer type of constructor of generic class (as with generic procedures)

    • Integrate LINQ and For Each

    No #light directive needed for it

  2. Please don’t do this, it’s unreadable!

  3. Kevin Ryall says:

    I have to say I really don’t like this idea – it makes the code much less readable for no obvious gain.  

    I did like Paul Vick’s idea of lower case keywords (I’m not sure why – it just looked ‘neater’), but this doesn’t appear to improve the appearance of the code at all.

  4. MarkJ says:

    Bad idea. But do you know what’s an even worse idea? Encouraging people to use IDE plugins to mangle standard VB into some weird custom language no-one else understands. How can we build a VB community if we can’t read other people’s code? Will Microsoft support cope with users who ask questions in weirdo language?  

    People have been creating weird custom languages for decades by mangling C and C++ with macros. Most respected programmers think it’s an appalling idea (Raymond Chen, Bjarne Stroustrop).


  5. Kyralessa says:

    Yuuuuuuuuuuuuck.  But I definitely like the idea of lower-casing the keywords.  Are we going to see that idea pop up in this series?

  6. Richard says:

    The more I think about this one, the more I think it’s a bad idea.  It is just too big a change for very little benefit.  Is it proposed only that the End Ifs etc be hidden (which would be OK but still cause potential confusion) or that the developer would be able to omit them entirely when writing new code?  The latter would mean that indentation would be syntactically significant, which is undesirable.  The former would be just as bad: it would look to the developer like the items could be omitted in new code, even though they actually couldn’t.

  7. Simon Geering says:

    Can’t remember who it was, mabe paul vick or someone, but they had a list of rules for VB and one of the fundamental ones was not to $%£& with the core fascets of the language. I would say this definatly falls into that bracket!

    It is hard eneough to when other devs write illegible code as it is without giving them more amunition!

  8. Nolowercase says:

    Please do not lower case keywords, it makes it ugly and when you press enter and ur variables capitalize as per ur declaration, u get feedback that uve typed ur variable correctly!! Also uppercased keywords and variables are much more beautiful

  9. I'm a bit of a latecomer to this discussion, but I really like the suggestion above (Donny) regarding property syntax. Especially with WPF, I make use of a LOT of properties, and they always end up completely overwhelming my classes. Each property requires two extra "End" lines. For even a dozen properties, that's an extra 24 lines of code that seem completely unnecessary – "End" could be inferred just as "Break" is inferred in a Select Case statement. The Set parameter is also a pain during refactoring. Many times I've changed the type of my several properties only to have to go back because I forgot to change the type of the Set parameter (especially annoying when the types are generally compatible, like upgrading from Integer to Long or something like that). I like the trimmed down property syntax in VB10, but it's useless since it doesn't allow me to implement the INotifyPropertyChanged interface in my Model classes (now that would be a fantastic feature).