Strings are Evil.
I believe that strings are the root of most bugs. As such, I try to avoid them as much as possible. This article isn't a conversation about Staticly-typed programming is better than Dynamically-typed programming. It is more about how to do Statically-typed development properly. And in My mind, properly means that the compiler is your strongest supporter.
If you write your code so you lean on your compiler, refactoring is much quicker. As soon as you change one item, everything else that relied upon it will break and prevent you from compiling. Then you simply need to go to those instances and make the appropriate changes. (Obviously refactoring tools can minimize this need).
If you have a lot of literal strings in your code you are left with:
- massive Find-n-Replace change where you hope you made the right changes
- resource-intensive testing of app
Use struct's, enums, constants or DTO's to define your application. They will provide you intellisense to eliminate typos. If you create wrapper classes around your Session object, for example, you are also guaranteeded that you
- do not duplicate key names
- ensure type safety
Wrappers around simple types, like objects or strings, allow you to centralize and control any conversions. This also prevents the need to use casting on assignments (i.e, CType() ). You use can also include comments that will appear in your intellisense to help guide other developers to use properly or understand implementational details.
If you do need to write code that is dynamic in nature (such as using reflection), make sure that the areas providing the mapping or logic are extremely focused. Force all conversion-related problems to exist in one spot. Like other dynamic languages, these areas should have a VERY strong reliance on unit tests and logging should something go wrong. Magical black boxes should be small and single purposed.
The setup time to direct your code to be reliant on the complier may be a bit longer than with a direct, brute-force attempt. The maintainability and reliabilty will pay off though.
Summary: Lean on your compiler now or cry on someone else's shoulder later.