"A hug is like a boomerang - you get it back right away."
I presented at IndyTechFest--a regional day of learning--last Saturday in Indianapolis. My topic was VB Tips and Tricks for VB 2010. As always I never leave such things to chance, so as I was heading to my session room I began corralling people towards my session. One victim said, "I don't use VB because I don't write business applications." Hunh?! Two things confound me routinely: why isn't everyone using CodeRush (to program faster) and why are there so many misconceptions about the Visual Basic language?
Being dogmatic about a programming language is like being dogmatic about spoken languages. I live in the US so I only need to know English. Again, huh?! No good ideas come from France, Germany, Russia or India?! I learn new programming languages and spoken languages because my experience is that you never know where a great idea will come from or which language it will be conveyed in.
A perfect example of sooner or later it will show up is auto-implemented properties. C# programming has had them since .NET framework version 2.0 but now VB has them. Auto-implemented properties are not complicated but they will save you some time and energy, so let's learn about them.
Using Auto-Implemented Properties
Twenty years ago or so programmers discovered that uninitialized fields or fields without logic resulted in bad data states. Function wrappers were invented to support logic around fields. As long as programmers were consistent about using functions instead of fields the idea was there would be less bugs. Many programmers chafed at this idea because fields were more convenient. The Auto-Implemented property was invented.
A property is a function wrapper that looks like a field but behaves like a function. The drawback was that many properties had no logic; they just set and returned field values. The result was a lot of extra coding and only marginal bang for the buck. As a result the auto-implemented property was invented.
An auto-implemented property implies that you can follow the canonical rule that properties are preferred but the shorter number of keystrokes needed to define a property was preferable. An auto-implemented property looks like this:
Public Property Foo As String
Notice that there are no getters and setters. When all a property does is set the backing field then use an auto-implemented property and refer to the property internally and externally to the class. The backing field is code-generated and exists as do the getters and setters, you just don't have to write them.
Now the clever skeptic is going to say why not use a field. That basically looks like a field. The answer is "Reflection". Aside from annoying the dogmatic gods of canonical rules, most of the .NET framework and components and controls Reflect against properties. Hence, if you revert to fields and bind your objects to something like the DevExpress XtraGrid or the WinForms DataGridView, it is not going to create columns for fields.
So, follow the rules--use properties--but take the shortcuts. It will save you time for real life stuff like reading to your kids.
Learn as much as you can about the .NET framework. Once you get past basic grammar in VB everything is about the framework. For example, knowing about auto-implemented properties for C# in 2.0 could inspire you to ask why VB doesn't have that cool feature. You and I already have to type more in VB than our C# counterparts, but we should have to do without.