-
Notifications
You must be signed in to change notification settings - Fork 138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[doc issue] JavaScript Coding Guidelines #169
Comments
Hi @punkratz312 , thanks for your contribution! Could you tell us which page of the UI5 developer guide you are referring to? Thanks. |
JavaScript Coding Guidelines -> Naming Conventions 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 ConventionsWe 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
}; |
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:
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. |
Hi @flovogt , I think this issue is in the domain of your dev team - what's your opinion? |
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
The text was updated successfully, but these errors were encountered: