Scott Hanselman

Stringly Typed vs Strongly Typed

August 03, 2021 Comment on this post [17] Posted in Musings
Sponsored By

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

Stringly TypedThere'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
select p

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.

About Scott

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.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
August 05, 2021 6:50
«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.»

The PL/SQL language comes to mind... https://www.oracle.com/database/technologies/appdev/plsql.html
August 05, 2021 8:58
Elephant in the room: National language support. When you deal with strings you must also accept regional spellings - making correctness even harder to verify. You might even call a perfectly defined API that returns a string and passes all your tests, only to find that your code breaks when you ship because you end up running in a different region; the API supports the region change but you don't - and you didn't test for it :-(
August 05, 2021 8:58
Elephant in the room: National language support. When you deal with strings you must also accept regional spellings - making correctness even harder to verify. You might even call a perfectly defined API that returns a string and passes all your tests, only to find that your code breaks when you ship because you end up running in a different region; the API supports the region change but you don't - and you didn't test for it :-(
August 05, 2021 9:46
People use Rust macros to verify validity of strings. For instance, the Rust printf equivalent verifies at compile time that the format string is valid. Same could be done for regexes, and I believe some SQL lib does that.

Not that I think that's ideal, but another thing to consider.
August 05, 2021 9:56
Instead of this:

string AddName(string firstName, string lastName);

do this:

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.
August 05, 2021 15:20
String typing is handled really well in typescript with string literals. That would have been a nice addition to this blog post.
August 05, 2021 17:15
I would go so far as to argue that any time one language is embedded inside another language and (inevitably) embedded as strings it's a mistake. We've **seen** the problems of SQL injection, and any time you force one stage to comingle code and data and force re-parsing, you're introducing *potential* issues.

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?
August 05, 2021 22:01
For specific implementations where you know all the bits and pieces upfront theres probably no good reason to use strings. However, when you're working on something highly generic, there often is no way around.

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.
August 06, 2021 13:03
In C# I use https://github.com/mcintyre321/ValueOf to avoid some of these issues.
August 07, 2021 10:25
All first names and last names should be registered with a central ledger and only their unique hash used in systems.
August 07, 2021 11:42
I agree with this POV and it irritates me when I see obvious things like ints and enums (c#) expressed as strings. However, the whole typo breaking logic due a bad switch statement thing to me sounds more like a missing automated test as the bigger fail. I’ve done Java for a while and the whole “everything has to be a class” mentality has its own drawbacks.

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.
August 07, 2021 14:16
JavaScript today has a major problem with stringly-typed code. Most libraries and code samples use this ava it's accepted as acceptable programming practice. Plain strings are used where constants or something like enums should be used. JavaScript doesn't have enums, but there are easy workarounds.
August 08, 2021 11:45
in c# you can you some value to avoid these issues.
and i think js has with stringly-type code.
tnq for this fantastic post
August 08, 2021 15:14
Thanks for tips i have some question from you how i can phone call with you ?
August 08, 2021 15:24
Whether it's stringly typed code or a primitive obsession, there's a cure for it provided by the language itself: types. I'm so happy seeing records being more adopted and considered a pattern for capturing such cases.
August 09, 2021 10:15
One of the best ones for skills development. Get More Details about Best Hotels In Dalhousie by clicking on this given links.
August 09, 2021 15:10
For me, the worst kind of String Typing is ... command lines in scripts. Especially when you have to handle arguments representing file names (or URLS, pick the one you prefer) potentially containing the exact same whitespace character usually meant to separate arguments.

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.