6 ms·

It is quite interesting to look how some of those recommendations change in the industry over time (to a degree you can make such general statements). For examp

by wuch 10y ago

It is quite interesting to look how some of those recommendations change in the industry over time (to a degree you can make such general statements). For example in Clean Code, Robert Martin argues against the idea of encoding type information into names (e.g., Hungarian notation suggested here) given that this can readily provided by IDE instead and enforced by strongly and static type system. Though, he _does_ recommend encoding information about arguments into function names. It seems that this recommendation to a large degree is a reflection of tools used. Nowadays it wouldn't be completely unusual for an IDE to show formal parameter name along with actual argument values passed, thus obviating the need to encode this information into the function name in the first place. Idea of robust data structures is very interesting. While storing additional information to detect potential misuse of API, like concurrent modification or iterator invalidation is common in other context, the idea of using it to correct the data structure is not the first thing that comes to mind.

Swizec 10y ago
And at the same time everyone in the JavaScript world is comfortable with using some hungarian-ish notation. $ is for jquery objects, Capitals are for classes, lowercase for instances, camelCase for methods and properties, UPPERCASE for constants, underscore_case for API values, snake-case for CSS classes. To name a few common conventions. None of this is enforced at the tools level.
- dualogy 10y ago
  Hungarian notation IIRC is specifically a 1-char-prefix of an argument names indicating type, ie. `goToWork (bTrth, sTxt, iCnt)` -- ie to reinforce type expectations -- rather than such casing conventions.. http://foldoc.org/hungarian%20notation http://foldoc.org/hungarian%20notation
  - Silhouette 10y ago
    Yes, that's more-or-less correct. The prefix wouldn't necessarily be only a single character. For example, using a "p" prefix for pointer values was a common convention in Microsoft ecosystem projects where Hungarian notation was probably most popular. Thus a pointer-to-char (char*) parameter might be prefixed with "pc". But yes, the fundamental idea was to convey information about the type of the variable as part of its name. That convention has mostly died out today, probably due to a combination of IDEs being used routinely in the ecosystem where the notation was most popular, and more recently due to modern languages having better type systems that enforce the rules objectively instead of relying on a convention. Ironically, with the popularity of dynamically typed languages today, we sometimes seem to have regressed to a point where interfaces to functions aren't always clear, and lots of avoidable bugs creep in due to passing incorrect types of data around. The emphasis on rapid evolution and ad-hoc/organic design we see with a lot of "agile" development processes isn't always helpful either. Put those together, and you almost have the complete opposite of the systematic design and robust processes advocated in the slides here.
    - throwawayish 10y ago
      > But yes, the fundamental idea was to convey information about the type of the variable as part of its name. No. There are two types of Hungarian Notation. The original one ("apps hungarian"), which made sense and sometimes still makes sense. Here you would assign a meaning to a prefix. For example, if you're writing MS Word a variable named "sWidth" might be the width of something in pixels on the screen (s), while "pWidth" might be the same width, but in logical units (say pt) on the page. Then you could have a function ptos, and it's easy to see whether variables were used correctly in computations - you can't mix screen-space and page-space coordinates without conversion. This made a lot of sense, because either variable would likely just be an "int". Similarly in a Python Webapp one might write "us_name" where us means UnSanitized. So before passing that anywhere else you know you need to sanitize it. See a "us_" variable somewhere that isn't a call to a sanitizer? Probably a bug! Then there's that other one, "system hungarian", which is the stupid thing everyone knows with stuff like lpcstrWindowName.
      - badsectoracula 10y ago
        Actually it would be something like cxPixels and cxPoints with c meaning "count", x meaning "horizontal" and Pixels/Point being the actual unit. You can see several Windows structs having this naming convention (the simplest one being SIZE which simply contains cx and cy). EDIT: people often see these as prefixes, but they are not really prefixes, the original paper was about the whole name.
      - Silhouette 10y ago
        All of your examples are still type information. They are more specific than the types provided by a basic C-style type system, but that's the point.
        temac 10y ago
        We can easily distinguish between the two by calling them units.
        10y ago
- mnsc 10y ago
  I knew that what you referred to as underscore_case was called snake_case so I had to find out what your "snake-case" (with dashes) is called. It's kebab case, or if the words are capitalized, train case. sh-i-sh-k-eb-ab----- I can see it! Choo-Choo-Train I can see it! So, carry on...
afro88 10y ago
Apple do this with their frameworks now with Swift 3, for these very reasons (strong typing + advanced IDE). There's no need to encode parameter names into the function definitions anymore, unless they're core data types. So now you have stuff like: view.convert(point, to: otherView) Which in Swift 2 was: view.convertPoint(point, toView: otherView)
dozzie 10y ago
> It is quite interesting to look how some of those recommendations change in the industry over time [...]. For example in Clean Code, Robert Martin argues against the idea of [...] Martin claimed in the very same book several ridiculous things (like not documenting short functions, which makes autogenerated documentation look awful; apparently Martin haven't ever used documentation generators before writing the book). It's hard to take Martin's recommendations as coming from "the industry".
- Silhouette 10y ago
  There's plenty one could reasonably criticise about Clean Code and some of Martin's other work, particularly in the context of building robust systems, but he is not wrong that Hungarian notation is mostly obsolete given modern programming languages and tool chains.
  - jwdunne 10y ago
    I agree. I found the "ideal" argument length of 0 (or I think 1) to be a bit ridiculous, though I was in the love affair period you have when you first start learning functional programming. I read (see below) that the idea of Hungarian notation was bastardised. The idea wasn't to encode type information as such, not in the primitives type sense. It was more to encode meaning succinctly. To use the example given, Position(x, y) is perfectly fine in Hungarian notation, because the variables tell us exactly what they are: the x and y coordinates as part of a point. The Hungarian notation we rip on would have us write Position(ix, iy). With the tools and type systems today, yeah, it's obsolete in the truest sense. Interesting piece of history none the less. I guess the real usefulness is the idea of encoding verbose information that our current tools and language do not support. That sounds better than encoding a primitive. https://blogs.msdn.microsoft.com/rick_schaut/2004/02/14/hungarian-notation/ https://blogs.msdn.microsoft.com/rick_schaut/2004/02/14/hung...

by wuch 10y ago

Swizec 10y ago

And at the same time everyone in the JavaScript world is comfortable with using some hungarian-ish notation. $ is for jquery objects, Capitals are for classes, lowercase for instances, camelCase for methods and properties, UPPERCASE for constants, underscore_case for API values, snake-case for CSS classes. To name a few common conventions. None of this is enforced at the tools level.

dualogy 10y ago
Hungarian notation IIRC is specifically a 1-char-prefix of an argument names indicating type, ie. `goToWork (bTrth, sTxt, iCnt)` -- ie to reinforce type expectations -- rather than such casing conventions.. http://foldoc.org/hungarian%20notation http://foldoc.org/hungarian%20notation
- Silhouette 10y ago
  Yes, that's more-or-less correct. The prefix wouldn't necessarily be only a single character. For example, using a "p" prefix for pointer values was a common convention in Microsoft ecosystem projects where Hungarian notation was probably most popular. Thus a pointer-to-char (char*) parameter might be prefixed with "pc". But yes, the fundamental idea was to convey information about the type of the variable as part of its name. That convention has mostly died out today, probably due to a combination of IDEs being used routinely in the ecosystem where the notation was most popular, and more recently due to modern languages having better type systems that enforce the rules objectively instead of relying on a convention. Ironically, with the popularity of dynamically typed languages today, we sometimes seem to have regressed to a point where interfaces to functions aren't always clear, and lots of avoidable bugs creep in due to passing incorrect types of data around. The emphasis on rapid evolution and ad-hoc/organic design we see with a lot of "agile" development processes isn't always helpful either. Put those together, and you almost have the complete opposite of the systematic design and robust processes advocated in the slides here.
  - throwawayish 10y ago
    > But yes, the fundamental idea was to convey information about the type of the variable as part of its name. No. There are two types of Hungarian Notation. The original one ("apps hungarian"), which made sense and sometimes still makes sense. Here you would assign a meaning to a prefix. For example, if you're writing MS Word a variable named "sWidth" might be the width of something in pixels on the screen (s), while "pWidth" might be the same width, but in logical units (say pt) on the page. Then you could have a function ptos, and it's easy to see whether variables were used correctly in computations - you can't mix screen-space and page-space coordinates without conversion. This made a lot of sense, because either variable would likely just be an "int". Similarly in a Python Webapp one might write "us_name" where us means UnSanitized. So before passing that anywhere else you know you need to sanitize it. See a "us_" variable somewhere that isn't a call to a sanitizer? Probably a bug! Then there's that other one, "system hungarian", which is the stupid thing everyone knows with stuff like lpcstrWindowName.
    - badsectoracula 10y ago
      Actually it would be something like cxPixels and cxPoints with c meaning "count", x meaning "horizontal" and Pixels/Point being the actual unit. You can see several Windows structs having this naming convention (the simplest one being SIZE which simply contains cx and cy). EDIT: people often see these as prefixes, but they are not really prefixes, the original paper was about the whole name.
    - Silhouette 10y ago
      All of your examples are still type information. They are more specific than the types provided by a basic C-style type system, but that's the point.
      - temac 10y ago
        We can easily distinguish between the two by calling them units.
        10y ago
mnsc 10y ago
I knew that what you referred to as underscore_case was called snake_case so I had to find out what your "snake-case" (with dashes) is called. It's kebab case, or if the words are capitalized, train case. sh-i-sh-k-eb-ab----- I can see it! Choo-Choo-Train I can see it! So, carry on...

afro88 10y ago

Apple do this with their frameworks now with Swift 3, for these very reasons (strong typing + advanced IDE). There's no need to encode parameter names into the function definitions anymore, unless they're core data types. So now you have stuff like: view.convert(point, to: otherView) Which in Swift 2 was: view.convertPoint(point, toView: otherView)

dozzie 10y ago

> It is quite interesting to look how some of those recommendations change in the industry over time [...]. For example in Clean Code, Robert Martin argues against the idea of [...] Martin claimed in the very same book several ridiculous things (like not documenting short functions, which makes autogenerated documentation look awful; apparently Martin haven't ever used documentation generators before writing the book). It's hard to take Martin's recommendations as coming from "the industry".

Silhouette 10y ago
There's plenty one could reasonably criticise about Clean Code and some of Martin's other work, particularly in the context of building robust systems, but he is not wrong that Hungarian notation is mostly obsolete given modern programming languages and tool chains.
- jwdunne 10y ago
  I agree. I found the "ideal" argument length of 0 (or I think 1) to be a bit ridiculous, though I was in the love affair period you have when you first start learning functional programming. I read (see below) that the idea of Hungarian notation was bastardised. The idea wasn't to encode type information as such, not in the primitives type sense. It was more to encode meaning succinctly. To use the example given, Position(x, y) is perfectly fine in Hungarian notation, because the variables tell us exactly what they are: the x and y coordinates as part of a point. The Hungarian notation we rip on would have us write Position(ix, iy). With the tools and type systems today, yeah, it's obsolete in the truest sense. Interesting piece of history none the less. I guess the real usefulness is the idea of encoding verbose information that our current tools and language do not support. That sounds better than encoding a primitive. https://blogs.msdn.microsoft.com/rick_schaut/2004/02/14/hungarian-notation/ https://blogs.msdn.microsoft.com/rick_schaut/2004/02/14/hung...