Frans Bouma's blog

Useless programming language constructs

Ok, I'm back! :) After a long period of extensive programming (AKA 'Crunch mode'), the pressure is finally gone. Everybody who has released a big software product knows that releasing it is one, but the period after the initial release is as important as the release itself: early adopters who find odd bugs in weird circumstances no beta-tester has thought about testing nor did yourself thought it would be possible etc. But that's for another story to tell later :)

Today, I want to discuss a small set of, In My Humble Opinion, useless programming language constructs. I find them useless because they do not serve a purpose at all, however you can't leave them out because doing so will result in non-compilable code. I ran into these when porting C# code to VB.NET or during C# development.

• break in case blocks.(C#). In C# you have to add a 'break;' statement after each statement group you define as the 'case' block. This is because you can't have 'fall through' in C# in switch/case statements. Example:

  switch(foo)
  {
     case 1:
        // some statements [A]
     case 2:
        // some statements [B]
  }

  'case 1:' will stop at the end of [A], because C# doesn't support fall through. However, you still have to specify 'break;' at the end of [A], because you can't fall through, but that is not supported anyway! So specifying break or not doesn't matter, the end result will be the same. Also, you have to specify 'break;' at the end of [B], even though it is the last case block in the switch.
• Overloads when Overrides (VB.NET). VB.NET has many odd constructs, but one of the most weird ones is the obligation to specify 'Overloads' when you override a method with 'Overrides', even when the overridden method is abstract! Isn't it so that when you override a method, there is always another version of it, so overriding a method is also overloading the original. You can't leave Overloads out of the definition, even when the overridden method is abstract, which is weird, because abstract methods are not executable, the implementation of the abstract method is not an overriding method (however you have to specify Overrides), it is the implementation of the method.
• WithEvents with form controls (VB.NET). When you are writing VB.NET without Visual Studio.NET (for example when you port C# code to VB.NET, you suddenly feel the power of the Visual Studio.NET editors: you leave out statements that are automatically added by these editors. One thing that I find weird in VB.NET and which is solved automatically by the VB.NET editor is the obligation to explicitly define 'WithEvents' with a control when you want to implement an event handler. So for example you have a button on a form, and when you leave out the 'WithEvents', you can't define an event-handler. However, what's the use of a button without events, besides a nice thingy on a form? Isn't it so that when a control exposes events you always should be able to define event handlers for these events, without having to rely on 'WithEvents' ?
• ReadOnly with properties with only a 'Get' (VB.NET). This statement falls in the same category as the C# switch-case-break statement. When you leave out ReadOnly, it will not compile. When you specify a Set, plus ReadOnly, it will not compile. Isn't it obvious that when there is just a Get and no Set, the property is ReadOnly? Why a statement to explicitly define it ReadOnly, as if there is another way to define it.

Ok that's it for now, I'm sure C# and VB.NET have more of these language constructs which make you wonder why they're there in the first place. If you know more, post them in the comments :)

Published Friday, September 19, 2003 2:30 PM by FransBouma