[evanmoran]

If you like this, my other favorite essay by Joel is Making Wrong Code Look Wrong:

https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...

[o11c]

The problem is that it completely ignores the correct solution, which is "use types; we invented them for a reason".

HTML fragments should never be stored in strings.

[mason55]

One problem is that there's a major lack of language support to make this easy.

IMO, every ID should be its own type. You shouldn't have a bunch of objects that have an ID of type string, you should have a User object with an ID of type UserID and a Post object with ID of type PostID, and then the compiler solves a lot of problems for you. Or make it so your functions that interact with the outside world accept a String, but they only return ValidatedStrings, and your internals only accept ValidatedStrings (and there's only one way to turn a String into a ValidatedString).

But in any kind of language with structural typing (e.g. TypeScript) this doesn't work, by definition. You can call a string a UserID and you can call it a PostID but if they're both Strings then you can assign them to each other.

And in Java, the concept of a typedef-like operation doesn't exist at all (I can't speak for .Net).

There's a whole class of bugs that go away if you allow for easy, nominal typedefs, but it's actually not easy to do in most statically typed languages.