[doc issue] JavaScript Coding Guidelines

[Pankraz76]

Issue description

I’m wondering why the official guidelines still promote patterns from the 80s, where development was done in raw text editors rather than in modern IDEs. In modern IDEs, type inference is actually possible—if not always accurate—whereas the old methods often lead to cluttered codebases.

There are numerous articles online pointing out the same issues, emphasizing that maintaining a clear codebase is preferable to enduring rare but confusing error messages. These errors can actually teach us to revise our code to fix critical issues.

When considering the Wikipedia article, there are more points against the old practices (12 cons) than benefits (10 pros). By simply following these numbers, you could argue that we are losing ground by introducing boilerplate code that leads to unnatural coding practices. Constantly revising code to comply with outdated rules—rules that the team has suggested moving beyond—only contributes to unnecessary clutter.

It would be beneficial for future developers to prevent such cluttering and improve code readability. Furthermore, I heard that you are migrating to TypeScript, so that’s kind of the direction it’s going anyway.

https://community.sap.com/t5/technology-blogs-by-sap/why-the-hungarian-notation-should-not-be-used-for-modern-sapui5-development/ba-p/13483943

Feedback Type (Optional)

None

Page Title on SAP Help Portal (prefilled)

No response

Page URL on SAP Help Portal (prefilled)

No response

[KvM2]

Hi @punkratz312 , thanks for your contribution! Could you tell us which page of the UI5 developer guide you are referring to? Thanks.

[Pankraz76]

JavaScript Coding Guidelines -> Naming Conventions
https://sapui5.hana.ondemand.com/#/topic/eded636b85584cd586b1fe231d2b5dac

Thanks for considering this 👍

Maybe it could be revised to transport the following, of course you can change the words to fit your needs.

Naming Conventions

We strongly discourage the use of Hungarian notation in modern JavaScript development, including SAPUI5. Hungarian notation, which prefixes variable names with their types, is widely regarded as an antipattern and poor practice. It introduces unnecessary complexity, making the code harder to read and maintain. Modern IDEs and tools already offer type information, rendering this approach obsolete.

Hungarian notation is particularly discouraged for API method parameters. Instead, rely on documentation or static type systems (e.g., TypeScript) for type checking.

Before (Hungarian Notation):

var sName = "John";
var iAge = 25;
var bIsActive = true;
var oUser = {
    sName: "Alice",
    iAge: 30
};

After (Modern Naming Convention):

var name = "John";
var age = 25;
var isActive = true;
var user = {
    name: "Alice",
    age: 30
};

[Pankraz76]

Thank you, everyone! You’re saving so many codebases, and with OpenRewrite, it’s like it never happened—we're not stuck back in the '80s anymore. Seriously, I’m a senior developer now with 15 years of coding experience. I recognize and understand this pattern, and I’ve been fortunate enough not to have been burdened with this kind of code, even though I've worked on many projects. It’s reminiscent of some mainframe and COBOL stuff, so I consider myself lucky to have moved on and adapted. I only know about this pattern from the literature.

Regarding Hungarian notation (antipattern) #371:

Indeed, it would be good to have a recipe to phase out this practice.

We will provide the recipe, and you can align with the best practice. As it was just a recommendation, it’s easy to be wiser now and revise.

openrewrite/rewrite-static-analysis#371

[KlattG]

Hi @flovogt , I think this issue is in the domain of your dev team - what's your opinion?

[flovogt]

@punkratz312 We will update the documentation and post an update here when we adjusted the respective sites.

[Pankraz76]

Thank you once again for the constructive collaboration – together, we are building a foundation for clearer, more modern, and future-proof code! 🚀

[flovogt]

I've implemented a fix (SAP internally (ui5-docs/PR#522). I will update this issue here as soon as the fix is available in this public repository.