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:

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! 👾