revise Hungarian notation (antipattern)

[Pankraz76]

It’s clear why Hungarian notation shouldn’t be used, but this doesn't prevent the actual mess from happening. The issue is that it still occurred. It should be quite simple to match and rename the fields accordingly, as only the prefix needs adjustment. Since the prefix is distinct (e.g., sString), matching based on this with a combination of lower and upper case letters makes it easy to revise. I would appreciate some snippets, and I’ll handle the coding to map all values from the Hungarian notation (an antipattern) and finally push this outdated practice back to the 80s, where it belongs.

References: SAPUI5 Guidelines Why Hungarian Notation Should Not Be Used in Modern SAPUI5 Development

[timtebeek]

Thanks for the offer to help @punkratz312 ! Indeed would be good to have a recipe to phase out this practice. What I can recommend here is to start a draft pull request containing just the tests and a skeleton recipe implementation, such that we can set the guard rails of cases to (not) handle. I could see there to be edge cases where there's both a sFoo and iFoo, or already and existing foo variable, all of which should be carefully considered.

Beyond the tests is might then help to look at closely matching existing recipes, such as these two (notice the links to source)

• https://docs.openrewrite.org/recipes/staticanalysis/renameprivatefieldstocamelcase
• https://docs.openrewrite.org/recipes/staticanalysis/renamelocalvariablestocamelcase

Also know that we have a VariableNameUtils; that looks at the wider scope to avoid any possible conflicts; that might make it easy to prevent the clashes with foo pointed out above.

I look forward to what you'll produce; and know that you're always welcome in our Slack if you have any further questions.

[github-actions[bot]]

This issue is stale because it has not had any activity for 60 days. Remove question label or comment or this will be closed in two weeks. Issues may be reopened when there is renewed interest.