He advocates prefixes on variable names. I would like to see good examples of this as I have never seen them as helpful (especially the tblUsers and intUserId type that can be common) .
All strings that come from [user input] must be stored in variables (or database columns) with a name starting with the prefix "us" (for Unsafe String). All strings that have been HTML encoded or which came from a known-safe location must be stored in variables with a name starting with the prefix "s" (for Safe string).
us = Request("name")
...pages later...
usName = us
...pages later...
recordset("usName") = usName
...days later...
sName = Encode(recordset("usName"))
...pages or even months later...
Write sName
s = Request("name")
[1] http://www.joelonsoftware.com/articles/Wrong.html
(edit: formatting, citation)
The article goes on to advocate prefixing the methods that return safe and unsafe strings with 's' or 'us' I would hate that! I can easily see you ending up with string methods like safePadLeft and unsafePadLeft that do exactly the same thing but are named for where in the code they are used...
Coding is hard, and as other comments have stated all these blog posts and books need to be condensed into 'balance' and that balance point is different for each coder, project and team.
I don't follow. Since the argument type to either method would be the same (a string), why are two methods necessary? Or are you inferring that we define subtypes of String: SafeString and UnsafeString? And wouldn't subtypes inherit behavior from their parent?
Advocating for prefixes like this is just going to result in badly obfuscated code where we get the exact opposite of, "JavaBeanFactoryConstructorXML_dom_to_json".
You're not supposed to write
iLength = iCount * iSize
but rather (something like)
meterLength = unitCount * meterSize
newtype UnsafeString = Unsafe String
(UnsafeString is the name of the type. Unsafe is the constructor you use to create an UnsafeString from the String).
With this and other techniques you can lift these characteristics of you data into the type system, which is IME much more useful than using hungarian notation.
Marking something unsafe is a best case scenario. Separating lines from rows would require a huge amount of boiterplate to preserve the numeric operations, and one still can not create a library that will check something like:
let
l = 5 :: Meter
w = 4 :: Newton
in l * w :: JouleNot sure what you mean by separating lines from rows. In the example you give of computing with units, I've seen examples of such systems in Scala (e.g. http://www.squants.com/) and F# comes with something built-in for this (IIUC). You might be interested in checking them out; it's quite neat.
It's the example Joe Spolsky used on the blog post about prefixes that everybody keeps pointing to. He showed code that worked on rows and columns (not lines, sorry) on a table, using prefixes to avoid mixing them.
Haskell types do support this use, but you'll have to declare both types as Integral and Numeric, with the resulting boiterplate. I'm not sure exactly how to solve this, maybe a way to "lift" typeclasses out of a newtype declaration would be general enough. It is probably possible to do with template Haskell, but that is already outside of the language.
That Scala library is interesting, although it looks like lots of the work is done at run time. Also, it looks like Haskell is able to do it [1]. (It's a recurring theme of mine, to complain that something can not be done on Haskell, just to discover somebody that did it.)
I assume that global variables would be horrible in such an environment, but typing out the prefix and maybe one letter of the actual name would cut the completion list down to a manageable size.
Perhaps apps hungarian started because it helped avoid common errors in complex GUI logic, then similar practices were carried over to the systems side where they were useful for mostly unrelated reasons, eventually reaching the world in general through the header files produced by the systems folks but lacking any of the context or history needed to go beyond "microsoft does it that way, there must be a good reason". Hopefully I'm just being overly pessimistic and extrapolating from massively insufficient information, though...
He eventually gets to "hungarian notation" (those redundant prefixes you don't like) towards the end of the piece. tl;dr: misinterpretation of a good idea, cargo-culted down through the ages.