3 ms·

I had a horrifying flashback to millions of lines of Hungarian Notation in Fortran and C++ when she described the prefixing for CSS classes. I'm not a frontend

by cjslep 10y ago

I had a horrifying flashback to millions of lines of Hungarian Notation in Fortran and C++ when she described the prefixing for CSS classes. I'm not a frontend developer, but is that really a good practice?

WorldMaker 10y ago
It's a common practice, particularly because CSS doesn't have easy to use namespaces or modules. Maybe not a "good" practice, because yeah so much as anything it's a sign that maybe we've reached the natural bounds of the CSS language and it's time to look into making it better.
adamlett 10y ago
The reason Hungarian Notation is considered bad practice is that it encodes in a variable name what is already, or at least ought to be, encoded in the variable’s type. CSS is not really a programming language, and it doesn't really have types.
- hackinthebochs 10y ago
  I never really understood the resistance to Hungarian notation. It greatly helps when you have large numbers of variables where their declaration is disconnected from their use (especially useful in languages like C++). That the information is redundant isn't a knock against it, it greatly reduces the friction in obtaining critical information about the variable. It certainly made reading windows code a 100x easier.
  - WorldMaker 10y ago
    The resistance has as much to do with the idea that the need to use something like hungarian notation in the first place is a failure of your tools/libraries. If that type information is so important, why isn't the compiler checking that type for you? Why can't your IDE follow the flow of that variable all the way back to its declaration and jump you to the declaration or provide tooltips/color-coding/"auto-hungarian"? It's easy to posit that the general prevalence of hungarian notation in early C/C++ is something of a clear indicator of deficiencies in the C/C++ languages themselves at the time. Why solve coding problems with cultural conventions and human dogma, when you can automate it or make a better language with a more formal type system?
    - nkassis 10y ago
      In addition Hungarian notation requires refactoring entire code bases whenever the type of something would change instead of the declaration point. Or become out of date as the type change but the variable name wouldn't. It also hinders legibility in my view but that's a personal opinion.
    - hackinthebochs 10y ago
      >why isn't the compiler checking that type for you? Why can't your IDE follow the flow of that variable all the way back to its declaration The strength of the type system is really an orthogonal concern here. Why jump around in your code when that information could be contained in its name? Why do we use descriptive names at all when we can just analyze how the variable is used to understand its meaning? Clearly, more descriptive names are almost always a benefit. The type of the variable also provides a significant portion of its meaning. It's a matter of having as much contextual information presented with the least amount of friction. Hungarian notation does this for strongly typed languages.
      - WorldMaker 10y ago
        I don't think that the strength of a type system is an orthogonal concern at all. I think there's a very distinct causation from the strength of the type system in C/C++ and hungarian notation. Much "weaker" dynamically typed languages typically don't see a need for it (Python, JS) and much stronger typed languages don't see a need for it (C#, ML family, Haskell). Hungarian notation, to me at least, finds most of its usage in a particularly painful "middle" of the strongly typed language spectrum where the language is strongly typed enough that subtle type differences are surprising footguns but not strong enough that the type system and compiler design provides you the tools/safeties to catch for you most cases when you are building a footgun. (With outliers like some BASIC variants whose typing system is a part of the variable naming system.) If anything, I think Hungarian notation is orthogonal to descriptive names. Sure, sometimes the type of something is useful descriptive information (though I'd argue rarely, even in strongly typed languages), but typically it's answers to the question "what is this variable for?" or "why does this variable exist at all?" I, at least, find more usefully descriptive. (Type information is pretty much never an answer to either question, it's much more to do with the mechanics of how the variable might accomplish its goals than what said goals actually are [1].) Certainly Hungarian notation has its places, and I'm not going to argue that it hasn't been useful in the history of languages, but I will argue that it's place in history is more as a historic tooling-related footnote than anything else. [1] The very rare exceptions that I know of are as you get into the deep end of super-strongly typed (mostly Haskell) stuff like type witnesses where knowing the type tells you everything and the type is almost more important than any actual variables of that type as the type has kind of suddenly "become" the algorithm.
- filoeleven 10y ago
  This is a bit offtopic but perhaps interesting: Joel Spolsky wrote an article, Making Wrong Code Look Wrong[0], which includes a defense of the original Hungarian notation--called Apps Hungarian--that I find rather convincing. Essentially, the original intent was not to encode the type in the variable name, but the kind. One example given is from the Excel codebase, where ints are used for tracking both rows and columns, but it doesn't make sense to assign values between them (save for rare circumstances like transposition). This is made explicit by prefixing rows with "rw" and columns with "col". If you ever saw something like "rwMax = colCurrent" it sticks out immediately as being wrong since you know that those two kinds of variables shouldn't mix. The assignment is legal and the compiler won't help you; the semantic naming scheme will. Encoding the type, like "ul" prefix for "unsigned long", is of course awful and unnecessary and deserves all the derision it has gotten over the years. [0]http://www.joelonsoftware.com/articles/Wrong.html http://www.joelonsoftware.com/articles/Wrong.html
  - deleted 10y ago
    [deleted]
Liron 10y ago
The only alternatives I can think of are (1) have the filename of the stylesheet reveal what type of style it is, and (2) stop acting like stylesheets are a better way to factor out UI code than React's JS-based component-oriented styling patterns. I personally do #2 but Pantsuit seems reasonable for sites that are relatively simple content + UI affairs (e.g. Wordpress) without a complex state-space (e.g. a T-shirt designer app).

by cjslep 10y ago

WorldMaker 10y ago

It's a common practice, particularly because CSS doesn't have easy to use namespaces or modules. Maybe not a "good" practice, because yeah so much as anything it's a sign that maybe we've reached the natural bounds of the CSS language and it's time to look into making it better.

adamlett 10y ago

The reason Hungarian Notation is considered bad practice is that it encodes in a variable name what is already, or at least ought to be, encoded in the variable’s type. CSS is not really a programming language, and it doesn't really have types.

hackinthebochs 10y ago
I never really understood the resistance to Hungarian notation. It greatly helps when you have large numbers of variables where their declaration is disconnected from their use (especially useful in languages like C++). That the information is redundant isn't a knock against it, it greatly reduces the friction in obtaining critical information about the variable. It certainly made reading windows code a 100x easier.
- WorldMaker 10y ago
  The resistance has as much to do with the idea that the need to use something like hungarian notation in the first place is a failure of your tools/libraries. If that type information is so important, why isn't the compiler checking that type for you? Why can't your IDE follow the flow of that variable all the way back to its declaration and jump you to the declaration or provide tooltips/color-coding/"auto-hungarian"? It's easy to posit that the general prevalence of hungarian notation in early C/C++ is something of a clear indicator of deficiencies in the C/C++ languages themselves at the time. Why solve coding problems with cultural conventions and human dogma, when you can automate it or make a better language with a more formal type system?
  - nkassis 10y ago
    In addition Hungarian notation requires refactoring entire code bases whenever the type of something would change instead of the declaration point. Or become out of date as the type change but the variable name wouldn't. It also hinders legibility in my view but that's a personal opinion.
  - hackinthebochs 10y ago
    >why isn't the compiler checking that type for you? Why can't your IDE follow the flow of that variable all the way back to its declaration The strength of the type system is really an orthogonal concern here. Why jump around in your code when that information could be contained in its name? Why do we use descriptive names at all when we can just analyze how the variable is used to understand its meaning? Clearly, more descriptive names are almost always a benefit. The type of the variable also provides a significant portion of its meaning. It's a matter of having as much contextual information presented with the least amount of friction. Hungarian notation does this for strongly typed languages.
    - WorldMaker 10y ago
      I don't think that the strength of a type system is an orthogonal concern at all. I think there's a very distinct causation from the strength of the type system in C/C++ and hungarian notation. Much "weaker" dynamically typed languages typically don't see a need for it (Python, JS) and much stronger typed languages don't see a need for it (C#, ML family, Haskell). Hungarian notation, to me at least, finds most of its usage in a particularly painful "middle" of the strongly typed language spectrum where the language is strongly typed enough that subtle type differences are surprising footguns but not strong enough that the type system and compiler design provides you the tools/safeties to catch for you most cases when you are building a footgun. (With outliers like some BASIC variants whose typing system is a part of the variable naming system.) If anything, I think Hungarian notation is orthogonal to descriptive names. Sure, sometimes the type of something is useful descriptive information (though I'd argue rarely, even in strongly typed languages), but typically it's answers to the question "what is this variable for?" or "why does this variable exist at all?" I, at least, find more usefully descriptive. (Type information is pretty much never an answer to either question, it's much more to do with the mechanics of how the variable might accomplish its goals than what said goals actually are [1].) Certainly Hungarian notation has its places, and I'm not going to argue that it hasn't been useful in the history of languages, but I will argue that it's place in history is more as a historic tooling-related footnote than anything else. [1] The very rare exceptions that I know of are as you get into the deep end of super-strongly typed (mostly Haskell) stuff like type witnesses where knowing the type tells you everything and the type is almost more important than any actual variables of that type as the type has kind of suddenly "become" the algorithm.
filoeleven 10y ago
This is a bit offtopic but perhaps interesting: Joel Spolsky wrote an article, Making Wrong Code Look Wrong[0], which includes a defense of the original Hungarian notation--called Apps Hungarian--that I find rather convincing. Essentially, the original intent was not to encode the type in the variable name, but the kind. One example given is from the Excel codebase, where ints are used for tracking both rows and columns, but it doesn't make sense to assign values between them (save for rare circumstances like transposition). This is made explicit by prefixing rows with "rw" and columns with "col". If you ever saw something like "rwMax = colCurrent" it sticks out immediately as being wrong since you know that those two kinds of variables shouldn't mix. The assignment is legal and the compiler won't help you; the semantic naming scheme will. Encoding the type, like "ul" prefix for "unsigned long", is of course awful and unnecessary and deserves all the derision it has gotten over the years. [0]http://www.joelonsoftware.com/articles/Wrong.html http://www.joelonsoftware.com/articles/Wrong.html
- deleted 10y ago
  [deleted]

Liron 10y ago

The only alternatives I can think of are (1) have the filename of the stylesheet reveal what type of style it is, and (2) stop acting like stylesheets are a better way to factor out UI code than React's JS-based component-oriented styling patterns. I personally do #2 but Pantsuit seems reasonable for sites that are relatively simple content + UI affairs (e.g. Wordpress) without a complex state-space (e.g. a T-shirt designer app).