Skip to Content
Technical Articles

Why the Hungarian notation should not be used for modern SAPUI5 development anymore

Whether you are an experienced or a new SAPUI5 developer you are probably using the Hungarian notation by Charles Simonyi for declaring your variables using the official SAPUI5 naming conventions:

Sample Type
sId string
oDomRef object
$DomRef jQuery object
iCount int
mParameters map / assoc. array
aEntries array
dToday date
fDecimal float
bEnabled boolean
rPattern RegExp
fnFunction function
vVariant variant types
pDialog promise

The convention or even the Hungarian notation itself has been introduced to clearly identify the type of a variable by just looking at its name.

So what’s wrong with this approach? 🧐

Basically nothing, sticking to this convention is just fine but not sticking to it combined with modern JavaScript features can simplify your code and hence make your life easier!

Before we jump into some real world examples there is one interesting statement which I came across when writing this blog post.

The German Wikipedia article on the Hungarian notation states that there has been a fundamental misunderstanding with the Hungarian notation itself:

“[…] wobei es zu einem grundlegenden Missverständnis kam. Simonyi spricht in seinem Paper vom „type“ einer Variablen, was vielfach als „Datentyp“ interpretiert wurde. Gemeint ist vielmehr die Art der Aufgabe einer Variablen im spezifischen Kontext einer Applikation. Es geht also nicht darum, ob eine Variable eine Ganz- oder Bruchzahl speichert, sondern, ob sie einen Zähler, eine Koordinate auf dem Bildschirm, oder einen Index in einem Array repräsentiert. Aus dem Variablennamen sollte man also die Bedeutung und nicht ihren Speichertyp erschließen können. […]”

Shortly and roughly translated and summarized:

What has been referred to as a “type” of a variable by Simonyi in his paper has been interpreted as a “data type”. But what Simony really meant by “type” was a speaking name regarding the usage of a variable rather than if it stores a float or a string value:

But the article / section has been marked as “controversial” so we can not rely on this statement.

Instead let’s have a look at a real world example which we will try to simplify by omitting the Hungarian notation and using some modern JavaScript features:

  readData: function (mOptions) {
    var that = this;
    return new Promise(function (fnResolve, fnReject) {
      var sPath = mOptions.path;
      var aFilters = mOptions.filters;
      var oModel = that.getModel();
      oModel.read(sPath, {
        filters: aFilters,
        success: function (oData, oResponse) {
          fnResolve({
            data: oData,
            response: oResponse
          });
        },
        error: function(oErrorResponse) {
          fnReject(new Error(oErrorResponse.message));
        }
      });
    });
  }

Here we have a generic readData function which wraps the callback based oModel.read function to return a proper Promise.

So how can we simplify this? 🤷🏼‍♂️

First let’s have a look at the official SAPUI5 naming conventions from above again which also states:

[…] do not use the Hungarian notation for API method parameters.

This is really the crucial point because there is always a mismatch between any method parameter and its value (e.g. “filters” vs. “aFilters”) for basically any SAPUI5 API method.

But it also allows us to simplify our code by not using the Hungarian notation and also using the JavaScript short notation for initializing objects  (which is already available as early as of EcmaScript 2015).

  // without Hungarian notation using shorthand property names (ES2015)
  readData: function (options) {
    var that = this;
    return new Promise(function (resolve, reject) {
      var path = options.path;
      var filters = options.filters;
      var model = that.getModel();
      model.read(path, {
        filters, // shorthand
        success: function (data, response) {
          resolve({
            data, // shorthand
            response // shorthand
          });
        },
        error: function (errorResponse) {
          reject(new Error(errorResponse.message));
        }
      });
    });
  }

Instead of writing e.g. “filters: aFilters” we can now simply write “filters” to set the API method parameter.

Okay this might seem not much but in the end it really sums up especially combined with other more recent JavaScript features such as Destructuring, Default Parameters, etc.:

  // modern JavaScript
  readData ({ path, filters = [] }) {
    return new Promise((resolve, reject) => {
      const model = this.getModel()
      model.read(path, {
        filters,
        success: (data, response) => resolve({ data, response }),
        error: ({ message }) => reject(new Error(message))
      })
    })
  }

Compared to our initial example this really makes a difference regarding the number of lines of code and the overall readability. ✅

And less code always means less code to be maintained (always think of your future you). 🚀

Additionally to not using the Hungarian notation I would also suggest to use a popular style guide like JavaScript Standard Style which is being used by Node.js, NPM and GitHub and is widely accepted across the JavaScript community.

Alternatives would be Airbnb JavaScript Style Guide or Google JavaScript Style Guide.

If you need to ship a version of your app which is also compatible with legacy browsers which do not support above JavaScript features you could use ui5-task-babel for transpiling your code.

A full example project can be found here: https://github.com/pwasem/bookshop-ui

 

Happy Coding! 👾

5 Comments
You must be Logged on to comment or reply to a post.
  • nice one. Just recently switched a project from "random notation" to hungarian, and had to cope with one or two similar scenarios. so in the end we ended up with "use hungarian notation unless you have a reason not to"

    Disclaimer: the following few lines are more a fun comment, not to be taken too seriously, though it has some truth to it

    Still having to cope with IE11 and still remembering the days when IE6,7,8 were in use albeit not being supported by Microsoft for years (and not expecting to completely avoid IE11 until Q4/2027, as that's the maintenance end of the current SAPUI5 LTM version 1.71 😀 ) ,

    my personal approach for browser code (since you have no control about the browser brand, version or JS version the user is using)

    • never use arrow functions
    • always use { data: data } rather than { data } notation
    • no fancy modern syntax.
    • if you need array functions, check their availability first (e.g. https://caniuse.com/array-find)

    It's just that I saw so many times younger colleagues failing with ui5, because they use the modern notations and "it works on their machine" but just wouldn't run on customers browsers...

    we live in a corporate world, and, more often than not, it is more efficient to use less efficient syntax than having to debug it later on.

    If you have full control over the JS version used at runtime (e.g. server side JS) - completely different story

    • That‘s where transpiling your code comes in:

      Develop using the latest features and ship a version which is even compatible with older browsers.

    • younger colleagues doing the right way. It is not their fault. It is because SAPUI5 development environment need another 250 years to adopt current methodologies. They have added transpiling for UI5-CLI recently. If UI5 developers also develop react/vue applications in parallel the will see how easy to write your code with new techniques and make it ready for even old browsers. (yarn build/ npm build )

       

       

  • Hi Pascal,

    thanks for this great post. I hope it triggers a vivid discussion.

    I got used to the Hungarian notation already a few years ago and it's still "in me". Sometimes, I use them inadvertently (even in backend JS) and then I wonder why I did this and go back to change the code again 😄. I agree, this notation feels kind of weird, and in most cases, it only reduces the readability of the code and doesn't provide much useful information.

     

    It would be interesting to hear from Peter Muessig what he thinks about this.

    • Hi Marius,

      thanks for your comment.

      With TypeScript and Transpile support for the UI5 Tooling on the horizon it is finally about time for UI5 developers to embrace modern JavaScript features and take their coding to the next level.

      Let's see about the  discussion, I am definitely up for it✌🏻😉