One of the least appealing features of BASIC was that it was a weakly typed language. “Weak typing” or “informal” typing means that the language lacks restrictions on declaring variables or that the language will implicitly convert variables behind the scenes. This typing system can facilitate (or even encourage) sloppy coding or, worse, potentially hide serious problems from being caught during testing. When Microsoft moved towards the .NET paradigm in the early 2000s, they began to clean up their fork of BASIC (Visual Basic) and make it into a language better suited to correct programming practices. Its .NET sibling C# was introduced as a language that provided the ease of use of Visual Basic, but with the superior semantics of C++.
One of the new features in C# in Visual Studio 2010 is the “dynamic” type. This type behaves, well, dynamically. It can be assigned any value or object. Any function name may be called on it. It may be passed as a parameter to any function. This necessarily means that any function involving a “dynamic” variable is late bound and not resolved until run time. For instance, all three of the code segments below will compile, but only the first one will run without an error.
dynamic num = 42;
dynamic x = 15;
For obvious reasons, it is not a best practice to write code with “late binding” – if you make a mistake, the compiler has no way of knowing.
Microsoft has a blog entry explaining the reason for the addition of this type – it allows you to easily consume legacy objects without mounds of code to handle antiquated constructs. While this is all well and good, Microsoft introduced a similar feature in Visual Studio 2010 for C++ called “auto”. With an “auto” variable, the actual type is automatically inferred at compile time based on the value assigned to the variable. So suppose a C++ programmer writes these two lines of code:
x = 2;
The second line is a compile error because the variable took upon itself the type of const char * when the first assignment occurred. This provides the flexibility of not having to write confusing code for legacy interoperability, but maintains a strongly typed language.
The moral of this story is that just because “dynamic” exists doesn’t mean that you have to use it. Proper coding practices prevent problems. It is important to remember that just because it compiles doesn’t mean it is right.
This, and other tips, tricks and special methods, are only a small sample of how our software applications engineers stay on top of new technologies and can help make your applications easier to use for your staff and clients. Talk to our eBusiness Solutions team today.
|Enjoy Your 30-day Free Trial!|
|Learn how Inbound Marketing Software can help your business grow!|