Stringly Typed vs Strongly Typed
I used to call this technique "type tunnelling" and noted its use in XML in 2005. When you are using a strongly typed language but instead your types are stringly typed, you are passing strings around when a better type exists.
Here's some examples of stringly typed method calls:
Robot.Move("1","2"); //Should be int like 1 and 2
Dog.InvokeMethod("Bark"); //Dispatching a method passing in a string that is the method's name. Dog.Bark()
Message.Push("TransactionCompleted"); Could be an enum
There's reasons to do each of these things, but as a general rule your sense of Code Smell should light up if you smell Stringly Typed things.
Inline SQL is another where one language (a proper language with Syntax) is tunneled as a string within another. There's no good solution for this as most languages don't have a way to express SQL such that a compiler could noticed a problem. Sometimes we'll see Fluent APIs like LINQ try to solve this. RegEx is another example of a string language within a language. Sometimes one will see large switch statements that fundamentally change program flow via "magic strings." One misspelling and your switch case will never fire.
Again, these have valid reasons for existence but you won't catch syntax issues until runtime.
LinqPad has a great post on why strongly typed SQL via LINQ or other fluent syntaxes are often better than SQL. Here's some LINQ in C# that will eventually turn into SQL. You get autocomplete and syntax warnings throughout the authoring process:
from p in db.Purchases
where p.Customer.Address.State == "WA" || p.Customer == null
where p.PurchaseItems.Sum (pi => pi.SaleAmount) > 1000
So why does it matter?
Regex rx = new Regex(@"\b(?<word>\w+)\s+(\k<word>)\b");
This isn't to say all Stringly Typed code is bad. It's to say that you need to make sure it doesn't just happen on its own. Be prepared to justify WHY it was written that way. Is string the only data type the app uses? Are there potential uses where something should be a Message or an Event or a Something and it was just easier or simpler to use a string? And here's the rub - was this Stringly Typed data structure pass to another component or service? Did you intend for its semantic meaning to be retained across this logical (or physical) boundary?
A great litmus test is "how would I catch a misspelling?" Compiler" Unit Test? Production ticket?
What do you think about Stringly Typed code? Do we type Name and Surname? Is that too far? Do we string all the things?
Sponsor: Pluralsight helps teams build better tech skills through expert-led, hands-on practice and clear development paths. For a limited time, get 50% off your first month and start building stronger skills.
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
Not that I think that's ideal, but another thing to consider.
string AddName(string firstName, string lastName);
FullName AddName(FirstName p1, LastName p2);
Use newtype for the second signature, that is all those types exist during compile time only and are string at runtime.
I'd argue further that modern languages/bindings shouldn't accept plain text strings *at all* for SQL queries. It wouldn't prevent idiotic/deliberately abusive use, but if we made it far more problematic to do so, surely we all win?
Working on a highly dynamic solution for something right now, yes, using a stringly typed aproach in various places and i don't even know what those strings might be while writing the code...
Guess there's a good reason these things are possible but you really have to think about if its needed for your specific case.
For Embedded SQL, I generally run the statement by itself, and sometimes it may have its own unit test. And if it’s complex I might make a resource file for it.
and i think js has with stringly-type code.
tnq for this fantastic post
Comments are closed.
The PL/SQL language comes to mind... https://www.oracle.com/database/technologies/appdev/plsql.html