Code Focused

Better Development Through Reading the Specs

Reading the Visual Basic language specifications may sound boring, but it actually reveals important information for developers.

• By Joe Kunk
• 09/21/2011

Better Development Through Reading the Specs

In order to be a proficient developer in any language, one must understand the language being developed in.  Despite this rather obvious statement, how many have ever looked at the Visual Basic language specification?  One of the best ways to know a language is in fact to read its specifications.

The Visual Basic language specification is written in clear language with many examples, and is a surprisingly interesting read. In this article I begin to examine the Visual Basic 10 language specification by looking at the feature compatibility policy and deprecation process contained in Chapter 1.

The Visual Basic language specification, written by Microsoft's Paul Vick and Lucian Wischik, is a freely available for download in HTML or Microsoft Word docx format.  The 600-page Word document has the following chapters:

Chapter 1. Introduction
Chapter 2. Lexical Grammar
Chapter 3. Preprocessing Directives
Chapter 4.  General Concepts
Chapter 5. Attributes
Chapter 6. Source Files and Namespaces
Chapter 7. Types
Chapter 8. Conversions
Chapter 9. Type Members
Chapter 10. Statements
Chapter 11. Expressions
Chapter 12. Documentation Comments
Chapter 13. Grammar Summary
Chapter 14. Change List

The language specification begins with an excellent overview statement of the benefits of developing in Visual Basic:

"The Microsoft  Visual Basic programming language is a high-level programming language for the Microsoft .NET Framework. Although it is designed to be an approachable and easy-to-learn language, it is also powerful enough to satisfy the needs of experienced programmers. The Visual Basic programming language has a syntax that is similar to English, which promotes the clarity and readability of Visual Basic code. Wherever possible, meaningful words or phrases are used instead of abbreviations, acronyms, or special characters."

It is this clarity and readability that makes developing in Visual Basic, and working with code developed by others, a natural and comfortable experience.

One well-known developer frustration is when a new version of the language causes compilation or functional errors in source code that ran fine in a prior version.  Section 1.2 of the specification discusses what constitutes a compatibility break, the criteria used to determine the impact of the compatibility break, the situations for which a compatibility break is acceptable, and the steps required to deprecate a feature and eventually remove it from the language.  Compatibility breaks are defined to include add in new warnings, features or keywords, correcting compiler or specification bugs, resolving specification ambiguity or omissions, converting runtime errors into compile-time errors, or mitigating a security concern.

Microsoft takes language version compatibility very seriously:

"compatibility between versions must be preserved except when the benefit to language consumers is of a clear and overwhelming nature."

Many developers have encountered a few situations where the language syntax or behavior seems counter-intuitive and wonder why Microsoft did not remedy the situation in the next version.  Section 1.2.1 offers an explanation why some undesirable features seem to lag in the language. Unacceptable reasons for breaking compatibility include:

"Undesirable or regrettable behavior. Language design or compiler behavior which is reasonable but considered undesirable or regrettable in retrospect is not a justification for breaking backward compatibility. The language deprecation process … must be used instead."

So what happens when a feature needs to be removed from the language? You may have seen a compiler warning similar to the one shown in Figure 1.  In May 2009, the ADO.Net team announced on their blog that the Oracle client would no longer be part of the ADO.NET roadmap.  The .Net 4.0 framework, as the first released version of the framework since the announcement, now includes the deprecation notice.

[Click on image for larger view.]

Figure 1. An example of a deprecated ADO.NET class

The deprecation process is designed to give developers significant time to find and implement alternates to the depreciated feature.  When a feature is determined to be deprecated after user community feedback, the following schedule applies:

• The next full (not point) release (current + 1) of Visual Studio will contain warnings of the deprecated usage that may be turned off, as well as being noted as deprecated in the product documentation and the web.
  
• The next full version release (current + 2) will be released with warnings that cannot be turned off.
  
• The next full version release (current +3) will be released with the warnings converted to compiler errors.  This  can be no sooner than the end of the Mainstream Support Phase time period for the version of Visual Studio that last contained the feature  (current version as of the time of decision to deprecate).  The Mainstream Support time period is currently five years. For example, the Mainstream Support End Date for Visual Studio 2010 [Editor: Please link "Visual Studio 2010" to http://support.microsoft.com/lifecycle/?LN=en-us&p1=14048&x=1&y=4] is 7/14/2015, five years after the General Availability Date of 6/29/2010.

Only after the deprecation process described above has been completed can the feature be removed from the language.

The Visual Basic 10 language specification contains a wealth of useful information to increase our understanding of Visual Basic and become a better developer.  This article presented the compatibility policy and the deprecation process detailed in the specification. Future articles will explore the useful and interesting facts contained in the remainder of the specification.