3 ms·

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-look-wrong/ http

• o11c 3y ago
  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 3y ago
    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.