3 ms·

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 t

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) .

jordanlev 11y ago
This old chestnut from Joel should be helpful (or at least entertaining): http://www.joelonsoftware.com/articles/Wrong.html http://www.joelonsoftware.com/articles/Wrong.html 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.
jt2190 11y ago
Christian points to Joel Spolsky's example of using prefixes to add meaning, not type information like your examples. From Joel's essay: 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 The thing I want you to notice about the new convention is that now, if you make a mistake with an unsafe string, you can always see it on some single line of code, as long as the coding convention is adhered to: s = Request("name") is a priori wrong, because you see the result of Request being assigned to a variable whose name begins with s, which is against the rules. [1] http://www.joelonsoftware.com/articles/Wrong.html http://www.joelonsoftware.com/articles/Wrong.html (edit: formatting, citation)
- HerpDerpLerp 11y ago
  Yeh I don't like abbreviations in code so would have unsafeName = Request("name") etc etc which does not have that problem... unless 'unsafe' is a thing in your business domain then things could get complex :) 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.
  - jt2190 11y ago
    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... 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?
    - bpchaps 11y ago
      Last time I inherited a project that used prefixes like this extensively, it was the most frustrating and productivity draining coding time of my life. Sure, it could work, I guess. If there was actually any consistency to it. So many hours lost trying to find out why a prefix was defined in two different ways.... 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".
- raverbashing 11y ago
  Joel advocates for correct Hungarian Notation, unfortunately people took it to put the language type of the variable (the compiler will check for that, obviously), but Hungarian Notation actually means you set a subtype to the variable so it helps with reading the code You're not supposed to write iLength = iCount * iSize but rather (something like) meterLength = unitCount * meterSize
- noelwelsh 11y ago
  In modern type systems (Haskell, etc.) you can define a new type that wraps an existing type with zero runtime cost. In Haskell you could write 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.
  - marcosdumay 11y ago
    I don't think the Haskell typing system is powerful enough for completely replacing prefix labels. 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 :: Joule
    - noelwelsh 11y ago
      Representing constraints in the type system is always an engineering tradeoff---how much type level machinery do you want to build vs the effort required to build that? Not 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/ 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.
      - marcosdumay 11y ago
        > Not sure what you mean by separating lines from rows. 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.) [1] http://hackage.haskell.org/package/dimensional http://hackage.haskell.org/package/dimensional
- Uristqwerty 11y ago
  I wonder how much of the later trend is due to the combination of early autocompletion and a codebase the size of windows or office, in a language where types can't be determined for sure without running each source file through the preprocessor. And most source files include the massive windows.h or some equally large hairball. 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 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) .

jordanlev 11y ago

This old chestnut from Joel should be helpful (or at least entertaining): http://www.joelonsoftware.com/articles/Wrong.html http://www.joelonsoftware.com/articles/Wrong.html 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.

jt2190 11y ago

Christian points to Joel Spolsky's example of using prefixes to add meaning, not type information like your examples. From Joel's essay: 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 The thing I want you to notice about the new convention is that now, if you make a mistake with an unsafe string, you can always see it on some single line of code, as long as the coding convention is adhered to: s = Request("name") is a priori wrong, because you see the result of Request being assigned to a variable whose name begins with s, which is against the rules. [1] http://www.joelonsoftware.com/articles/Wrong.html http://www.joelonsoftware.com/articles/Wrong.html (edit: formatting, citation)

HerpDerpLerp 11y ago
Yeh I don't like abbreviations in code so would have unsafeName = Request("name") etc etc which does not have that problem... unless 'unsafe' is a thing in your business domain then things could get complex :) 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.
- jt2190 11y ago
  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... 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?
  - bpchaps 11y ago
    Last time I inherited a project that used prefixes like this extensively, it was the most frustrating and productivity draining coding time of my life. Sure, it could work, I guess. If there was actually any consistency to it. So many hours lost trying to find out why a prefix was defined in two different ways.... 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".
raverbashing 11y ago
Joel advocates for correct Hungarian Notation, unfortunately people took it to put the language type of the variable (the compiler will check for that, obviously), but Hungarian Notation actually means you set a subtype to the variable so it helps with reading the code You're not supposed to write iLength = iCount * iSize but rather (something like) meterLength = unitCount * meterSize
noelwelsh 11y ago
In modern type systems (Haskell, etc.) you can define a new type that wraps an existing type with zero runtime cost. In Haskell you could write 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.
- marcosdumay 11y ago
  I don't think the Haskell typing system is powerful enough for completely replacing prefix labels. 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 :: Joule
  - noelwelsh 11y ago
    Representing constraints in the type system is always an engineering tradeoff---how much type level machinery do you want to build vs the effort required to build that? Not 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/ 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.
    - marcosdumay 11y ago
      > Not sure what you mean by separating lines from rows. 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.) [1] http://hackage.haskell.org/package/dimensional http://hackage.haskell.org/package/dimensional
Uristqwerty 11y ago
I wonder how much of the later trend is due to the combination of early autocompletion and a codebase the size of windows or office, in a language where types can't be determined for sure without running each source file through the preprocessor. And most source files include the massive windows.h or some equally large hairball. 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...