Update methods

[KhanbalaRashidov]

No description provided.

[github-actions]

Thank you for submitting your first pull request, awesome! 🚀 If you haven't already, please take a moment to review our contribution guide. This guide provides helpful information to ensure your contribution aligns with our standards. A core team member will review your pull request.

[sebastienros]

I already wrote my personal opinion on these PRs that you have opened, at least on the repositories I am involved: dotnet/aspire#4747 (comment)

[Piedone]

Agree with Sebastien.

Currently, we do such formatting changes/decisions case-by-case, according to the personal preference of the author. This is not a good approach, and rather we should make decisions for each style yes or no, have the debate closed, and introduce code analysis (#7950) to enforce the selected one.

Right now, this doesn't really bring much benefit but introduces friction by creating a conflict for each PR (and we'll still introduce new discrepancies until analyzers are employed). I'm personally for expression-bodied members, but this doesn't matter here.

Until then, while I thank you @KhanbalaRashidov for your contribution, I don't think we should apply rules for the whole codebase. And please do consider contributing to Orchard Core again; however, keep the above-linked contribution guide in mind, including:

First, identify the scale of what you would like to contribute. If it is small (grammar/spelling or a bug fix) feel free to start working on a fix. If you are submitting a feature or other substantial code contribution, please discuss it with the team first and ensure it follows the roadmap and fits into the bigger picture. We'd hate to see your work go to waste! The best is if you work on open issues, and open an issue for your idea too, before starting coding.

[KhanbalaRashidov]

Agree with Sebastien.

Currently, we do such formatting changes/decisions case-by-case, according to the personal preference of the author. This is not a good approach, and rather we should make decisions for each style yes or no, have the debate closed, and introduce code analysis (#7950) to enforce the selected one.

Right now, this doesn't really bring much benefit but introduces friction by creating a conflict for each PR (and we'll still introduce new discrepancies until analyzers are employed). I'm personally for expression-bodied members, but this doesn't matter here.

Until then, while I thank you @KhanbalaRashidov for your contribution, I don't think we should apply rules for the whole codebase. And please do consider contributing to Orchard Core again; however, keep the above-linked contribution guide in mind, including:

First, identify the scale of what you would like to contribute. If it is small (grammar/spelling or a bug fix) feel free to start working on a fix. If you are submitting a feature or other substantial code contribution, please discuss it with the team first and ensure it follows the roadmap and fits into the bigger picture. We'd hate to see your work go to waste! The best is if you work on open issues, and open an issue for your idea too, before starting coding.

Thanks @Piedone