Blazor access modifiers and field underscores

[guardrex]

For Blazor templates per dotnet/AspNetCore.Docs#15853 (comment) ...

• Few access modifier touches.
• Underscores for fields.
• Alphabetize class properties and place properties before methods.
• [Parameter] on its own line.
• Summaries, a private static readonly string[] field, is named like a constant (capitalized). If that's by-design, I'll revert.
• I swap in an underscored field for this.logger = logger in WeatherForecastController.cs. I thought this was "banished to the land of wind and ghosts (-RN)." If by-design, I'll revert. Reverted!

[rynowak]

I swap in an underscored field for this.logger = logger in WeatherForecastController.cs. I thought this was "banished to the land of wind and ghosts (-RN)." If by-design, I'll revert.

BTW - whether or not we're doing this. or _ in templates is currently under civil debate. We're not currently very consistent about it, because it was largely a decision made by the people who wrote the code and their preferences.

That doesn't sound like me, I'm part of #ThisSquad 😁

[guardrex]

Mentioning the guideline for discussion only in case anyone else sees this. I know that ur aware of the lingo 😄 ...

Avoid this. unless absolutely necessary

From: https://github.com/dotnet/aspnetcore/wiki/Engineering-guidelines#coding-style-guidelines--general

I performed a doc sample search to see how common this is used ... very rarely ... half-dozen times or so in mostly obscure samples. This one tho, WeatherForecastController is going to be seen quite a bit I think. 👀

[pranavkm]

@guardrex we spoke about this offline, and the decision was to land close to what VS does by default which is to use this.. This of course only applies to content that lands in user's projects (templates and scaffolded code), and not to our engineering guidelines. Would you like to take a stab at updating this or should we close this?

[guardrex]

I can update this ... I think the rest of the goodies on here are ok. I'll take care of it tomorrow (Wednesday) NOW.

[guardrex]

@pranavkm ... Had a minute while 🍗 was cook'in. 👨‍🍳 Updated!

[pranavkm]

The ones above I'm 😐 about since they're sample. However, going by my discussion, we would use this. to disambiguate locals versus global, and not prefix items with underscores.

[guardrex]

Nevermind my last remark here. I'm rambling a bit.

Let's close this. If a docs issue is opened to conform doc examples/samples to different coding style than the one we have, lay out the rules for me in the new docs issue. I'll go through and conform everything to the guidance.

Currently, the docs follow this pattern:

• this isn't used in any Blazor sample or example. IIRC, this did appear in a few engineering code examples/samples that were handed to me, but I removed it in those cases ... placing me in the #NotThisSquad 😄. Those PRs were signed off on review, so I guess reviewers weren't too upset about my actions at the time.
• All fields in @code blocks use an underscore.
• I don't think we have any classes in @code blocks or Razor explicit expressions; but if we ever do, my intention is not to use underscores in those scenarios.
• Members are explicitly marked private when that's the case.

The docs are internally consistent. The only discrepancy is between what devs see in a template-generated app and the docs. That's where I think devs might become confused 😵.