Code Focused
Making Sense of Class Modifiers in C# and Visual Basic
Both are .NET Framework-based, but they don't seem to be speaking the same language.
Visual Basic and C# are like two peas in a programming pod. Both languages use the .NET Framework as the foundation for data and code processing, so naturally there's a lot of overlap in how they approach computing problems. And yet, there are times when they can't understand a single thing the other language is saying.
It's all those weird keywords that don't match up. I'm sure there are perfectly valid historical reasons why C# employs the "using" keyword instead of the equivalent Visual Basic "Imports" keyword. But what good is history when you need to get a code sample converted from one language to the other?
Consider the keywords that decorate class declarations in both languages. Table 1 lists the valid modifier keywords that you can include in a C# "class" statement, or in the matching Visual Basic "Class" statement.
Table 1: Modifier Keywords for Class Declarations
| C# Modifier |
Visual Basic Modifier |
| abstract |
MustInherit |
| internal |
Friend |
| new |
Shadows |
| partial |
Partial |
| private |
Private |
| protected |
Protected |
| protected internal |
Protected Friend |
| public |
Public |
| sealed |
NotInheritable |
| static |
Not supported |
|
A few of the cross-language keywords are the same, especially with access-level modifiers like Private and Protected. But some of the more terse C# keywords have equally interesting but otherwise unrelated equivalents in the Visual Basic world. And isn't the C# language's "new" keyword a bit overused?
Fortunately, most of these differences are in name only, and those variations can tell you a lot about the underlying languages. Visual Basic terms like MustInherit and NotInheritable are clear and explicit, a continuation of the historic simplification goals of the BASIC family of languages. Likewise, C# terms like abstract and sealed are raw and technical, evoking the closer relationship that developers of C-like languages have had with the underlying computer science constructs.
The table also communicates an important implementation difference between the two languages: The lack of a "static" modifier for Visual Basic classes. Visual Basic includes the Module type, which provides a construct not unlike C# language static classes:
// ----- A typical static class in C#
static class UsefulFeatures
{
public static DateTime LocateThreeAM(DateTime someTime)
{
return someTime.Date.AddHours(3);
}
}
' ----- The same static class in Visual Basic
Module UsefulFeatures
Public Function LocateThreeAM(ByVal someTime As Date) As Date
Return someTime.Date.AddHours(3)
End Function
End Module
Clearly, Visual Basic can do static classes. But for reasons of history and clarity, it retained an earlier Module-based syntax, rather than adding a "Shared Class" syntax to its .NET implementation.
Little surprises like this pop up all over the languages. The content in Table 1 comes directly from the book "C#-Visual Basic Bilingual Dictionary: Visual Studio 2015 Edition" (Owani Press, 2015), and its pages are thick with these surprising yet understandable language differences. If you have the chance to work with code samples between the languages, be on the lookout for how syntax differences provide clues to the usage and history of each programming environment.
About the Author
Tim Patrick has spent more than thirty years as a software architect and developer. His two most recent books on .NET development -- Start-to-Finish Visual C# 2015, and Start-to-Finish Visual Basic 2015 -- are available from http://owanipress.com. He blogs regularly at http://wellreadman.com.