My Regression in Dynamically Typed Languages, Revisited

Yesterday, I wrote a post about some of my issues and gripes with dynamically typed languages. Though the post itself didn’t generate a lot of conversation in the comments, I ended up having a good chat via Twitter with a number of developers whom I greatly respect.

In these particular conversations, I was challenged both in terms of how I leverage the dynamic features certain programming languages, as well as how I use certain forms of notation (namely, Hungarian Notation).

Challenge Accepted

I can’t cover everything that I’d like to cover in a single post partially because I’m not certain – at least at this point in time – I’d  change my opinion on everything I wrote.

However, out of the conversations that I did have, I think one point that’s worth clarifying is my opinion on using Hungarian Notation in dynamically typed languages and how the environment can change whether or not I use it.

Hungarian Notation in Dynamically Typed Languages

It’s obviously and abundantly clear that I spend the majority of my time working in WordPress, and thus I spent the majority of my time working with:

  • CSS (or a set of preprocessors)
  • JavaScript
  • PHP
  • HTML
  • MySQL
  • …and so on

When I mentioned that I’m a fan of Hungarian Notation, I should have clarified that I’m not necessarily a fan of using it within the context of WordPress-specific PHP.

For notation, I think context matters.

Contextual Dependent Notation

I dunno – I made that headline up because I don’t know of what other term to call this.

Anyway, what I mean is that I personally do not use – nor do I recommend – deviating from the standard WordPress coding conventions. So when it comes time to, say, working with post meta data, you aren’t going to find me using variables such as $i_post_id or $str_meta_key.

Instead, I follow with the conventions that WordPress uses. That is, $post_id, $meta_key, $term, $term->term_id, $query, $title, and so on.

The reason that I don’t see a need to use any kind of notation in this context is because the environment itself gives enough contextual clues as to what kind of data each variable should hold. In other words, these map to the titles of the columns to which the data they store refers.

For example, a post ID is always going to be a number. When I pass TRUE to the get_post_meta function, I’m going to be getting back a string; otherwise, I’ll be getting an array. This is documented, well-known information.

So why would I need to break conventions when WordPress using a specific naming convention, and the general development community knows what data type the variable represents?

Non-Contextual Dependent Notation

Again, I just negative the first heading since I have no real idea as to what I call this particular strategy of naming variables.

But this isn’t always the case when I’m working on, say, a JavaScript utility – be it a jQuery plugin, a JavaScript function, or something similar.

To be completely clear: It’s a different story if it’s independent of a specific platform.

So to that end, yes, I’m still a fan of Hungarian Notation because I prefer my variables to read like:

  • bHasData
  • sUrl
  • fAmount
  • …and so on

And I honestly do that more within JavaScript that any other language (though this isn’t to say I haven’t done so in, say, pure PHP applications).

I’m Not Flip-Flopping

I know, I know – here I am adding more content to a post that I wrote about 24 hours ago. But given the nature of the conversations I had, I felt that it was worth clarifying a couple of points about my preferences rather than making more generalized statements (that were more in the form of notes than anything else).

If I do flip flop, you better believe it's gonna be fancy.
If I do flip flop, you better believe it’s gonna be fancy.

So the truth is that I’ll likely have more to share about this in the future in even more detail, but, for now, perhaps this clarifies a little bit about where I’m coming from.

Even still, I’m interested in hearing everyone else’s take on it, so let me know via Twitter, the comments, or however you like to chat.

4 Replies to “My Regression in Dynamically Typed Languages, Revisited”

  1. My general opinion on this is that code needs to be lucid. The complexity of the code itself can vary depending on what it’s doing, but I find Hungarian notation in general leads to code that is difficult to read. I’ve worked in an environment where this was taken to the nth degree with a large type system and rules around what prefixes such instances can take. Not pretty, and not scalable.

    The other reason I think it has little use in Dynamic Languages is Duck Typing. It shouldn’t matter what the type of a variable is as long as it responds correctly to a method. How the object goes about responding is immaterial as long the result is valid.

    A better alternative especially in dynamic languages is Tests. They help clarify meaning with real world implementation context. I’ll take a codebase with a test suite over a consistently named Hungarian notation codebase any day.

    1. I find Hungarian notation in general leads to code that is difficult to read. I’ve worked in an environment where this was taken to the nth degree with a large type system and rules around what prefixes such instances can take. Not pretty, and not scalable.

      With a wide array of types, I absolutely agree.

      But for primitives in a language like JavaScript? It’s always served me well. Of course, I’ll be the first to admit that I’m always open to changing my habits for the better.

      This post is just a snapshot of where I am in time.

      It shouldn’t matter what the type of a variable is as long as it responds correctly to a method. How the object goes about responding is immaterial as long the result is valid.

      But this can be the inherent problem: it may react one way when, really, it should be reacting in a completely different way because the interpreter coerced the value and did so incorrectly.

      A better alternative especially in dynamic languages is Tests.

      Agreed. Absolutely. It’s a shame some projects don’t build in time for tests, but I do what I can to include them when I can.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.