Skip to content
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

Open
punkratz312 opened this issue Oct 15, 2024 · 6 comments
Open

[doc issue] JavaScript Coding Guidelines #169

punkratz312 opened this issue Oct 15, 2024 · 6 comments
Assignees
Labels
follow-up-with/po Clarification with product owner needed. in-discussion This item is being discussed internally

Comments

@punkratz312
Copy link

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
Copy link
Contributor

KvM2 commented Oct 15, 2024

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

@punkratz312
Copy link
Author

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
};

@KlattG KlattG added follow-up-with/po Clarification with product owner needed. in-discussion This item is being discussed internally labels Oct 16, 2024
@punkratz312
Copy link
Author

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 KlattG assigned flovogt and unassigned KlattG Oct 29, 2024
@KlattG
Copy link
Contributor

KlattG commented Oct 29, 2024

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

@flovogt
Copy link

flovogt commented Nov 14, 2024

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

@punkratz312
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
follow-up-with/po Clarification with product owner needed. in-discussion This item is being discussed internally
Projects
None yet
Development

No branches or pull requests

4 participants