

Making Wrong Code Look Wrong (2005) - blackswan
http://www.joelonsoftware.com/articles/Wrong.html

======
tome
I like the ideas expressed but I'd rather see them enforced by the language
than by coding convention. For example to simulate type checking you could
prefix _typename onto each of your variable names. Then

i_int += j_filehandle

would stick out as wrong. But luckily many languages support type checking so
we don't have to do it in those languages!

I wonder is it possible to avoid mixing safe and unsafe strings (for example)
using some new language feature (or a new use of an old one)?

~~~
rtra
You can do that in Haskell easily.

    
    
      data UnsafeString = Unsafe String
      htmlencode :: String -> String
      sanitizeUnsafeStr :: UnsafeString -> String
      sanitizeUnsafeStr (Unsafe cs) = htmlencode cs

~~~
Jebdm
You can do it in any OO language easily as well. For instance, in Python:

    
    
      class UnsafeString:
        def __init__(self, str):
          self._str = str
          self._sanitized = None
        def __str__(self):
          return self.sanitize()
        def unsafe(self):
          return self._str
        def sanitize(self):
          if self._sanitized != None:
            return self._sanitized
          else:
            self._sanitized = sanitize(self._sanitized)
            return self._sanitized
    

That way, as long as you wrap all input in the UnsafeString class, you'll have
to be explicit if you want the unsafe version and you'll get the safe version
by default.

~~~
rtra
Precisely. Isn't user input handled like this on most web code? It seems the
most sensible way to do it.

------
smanek
Well, my first thought would be using macros to ensure you never have 'unsafe'
strings anywhere.

But, for some inexplicable reason, Joel says "Don’t use macros to create your
own personal programming language."

How is using macros to encapsulate common functionality any different than
using functions to encapsulate common functionality? Both lead to less mental
overhead, more code reuse, and code that's easier to parse.

~~~
ChadB
Given the overall theme of this rant, I would assume that it's about keeping
code close together and easy to understand.

Obviously, macros have almost nothing in common with functions. Macros are
simply shorthand for code that will be literally placed at the spot they are
called.

So rather than calling functions, with all argument expressions evaluated, and
a call stack, and blah blah blah, you are just copy-pasting code without it
actually ending up on the screen for a developer to see.

~~~
smanek
You really think that macros have almost nothing in common with functions?
Granted that the semantics are a little different but, in my mind, macros and
functions are just two different tools that serve the same goal: allowing for
code reuse.

(I do understand the difference, for what it's worth. I worked as a
professional Common Lisp coder for a while.)

~~~
kaens
Well, I don't think he's talking about Common Lisp macros.

------
Herring
I don't quite buy his argument about why we need to keep things in unsafe
format for a while. If that credit card app can't handle HTML-encoded stuff,
how would it handle evil javascript?

~~~
jmtulloss
In general, I find that it's a bad idea to destroy information. Keep all input
intact as long as possible, so if you ever do encounter a problem, you don't
need to reconstruct the original data. You can always process data into the
correct form at runtime.

Of course, there are performance implications to this, but those can be dealt
with. Encoding strings right away for performance reasons is definitely a
premature optimization.

