Corrected casing of Typo enum members (2nd attempt)

[Yomodo]

Description

I've corrected the casing of the Typo enum members.
e.g. Typo.body1 -> Typo.Body1, Typo.subtitle1 -> Typo.Subtitle1 and so on.

The attributes are left untouched: [Description("subtitle1")] as this will wreak havoc in the Docs.

How Has This Been Tested?

Visually; Browsing through the Docs and comparing it with the online Docs.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• The PR is submitted to the correct branch (dev).
• My code follows the code style of this project.
• I've added relevant tests.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.07%. Comparing base (27e54b3) to head (16777ca).

Additional details and impacted files

@@            Coverage Diff             @@
##              dev    #8499      +/-   ##
==========================================
+ Coverage   89.01%   89.07%   +0.06%     
==========================================
  Files         411      411              
  Lines       12175    12175              
  Branches     2431     2431              
==========================================
+ Hits        10837    10845       +8     
+ Misses        803      796       -7     
+ Partials      535      534       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ScarletKuro]

I will let other team members to take a decision on this PR.
I know that C# enums are in PasalCase, and I prefer enums to follow the general C# rules.
But I don't know the intentions, maybe the idea was to align it in the lowercase just like it's in the HTML / CSS.
This is also a massive change, while existing breaking change might influence not everyone, this one probably will affect every single mudblazor customer.

[danielchalmers]

I agree in theory but like @ScarletKuro said it would be super breaking. I don't really see the value gained in bikeshedding it at this point since it's functionally the same. I would keep it lowercase.

[mikes-gh]

For sure it's to follow html casing.
For me with everything that's changing this is too big a change and I think the C# rules are broken intentionally in this case @Garderoben ?

[Yomodo]

The secondary reason for doing this PR it that it seemed like a good time, with all the breaking changes going on.

My primary reason is that the lowercase names have been bothering me since I started using MudBlazor +-5 years ago,
If it's a no-go that's also fine; I've learned to "live" with this over the years. 😀

[henon]

We had arguments for it and arguments against it. I have one for the middle ground. What if we make a non-breaking change in v7, obsolete the lowercase enum members and remove them in a later breaking release after the user base has had enough time and warning?

[Yomodo]

How about I create a new PR that ONLY does this for now so that nothings breaks.
Separate PR's can later be merged to gradually migrate away.

Update: Not that good as intended because it'll raise compile errors, forcing people to still modify code.

public enum Typo
{
    [Obsolete("This will be removed in v7")]
    [Description("inherit")]
    inherit,
    [Description("inherit")]
    Inherit,

    [Obsolete("This will be removed in v7")]
    [Description("h1")]
    h1,
    [Description("h1")]
    H1,
   ...
}

[henon]

Of course in our code base we'd have to replace all usages because warnings are errors for us. But that would be very easy to do with Find And Replace

[henon]

Update: Not that good as intended because it'll raise compile errors, forcing people to still modify code.

Only if you treat warnings as errors. Most don't do this.

[ScarletKuro]

Only if you treat warnings as errors. Most don't do this.

[Obsolete("This will be removed in v7", true)]? It will force them to update, since they won't be able to compile.

[danielchalmers]

We had arguments for it and arguments against it. I have one for the middle ground. What if we make a non-breaking change in v7, obsolete the lowercase enum members and remove them in a later breaking release after the user base has had enough time and warning?

But what is ultimately gained from making this change? Even with advanced warning it still seems like pure busywork. Does it being lowercase break anyone's workflow?

[henon]

I guess I have no counter argument to that @danielchalmers ;)

[Yomodo]

We have the 'Treat warnings as errors' enabled as well.

Ultimately there is nothing to gain; things don't get faster or better, and I can also
understand the argument of too many changes.
But such an argument also feels kind of blocking for future refinements.

So, I think it then depends on how strict one would want to follow
a naming convention and in that regard I'd say either follow it all the way or don't.

[danielchalmers]

But such an argument also feels kind of blocking for future refinements.

Refinements are great but you have to weigh the pros and cons. The con in this is breaking every user and also documentation like answers on StackOverflow etc.

[Yomodo]

Refinements are great but you have to weigh the pros and cons. The con in this is breaking every user and also documentation like answers on StackOverflow etc.

This reasoning is how we built a lot of code-debt over the years.

[danielchalmers]

Refinements are great but you have to weigh the pros and cons. The con in this is breaking every user and also documentation like answers on StackOverflow etc.

This reasoning is how we built a lot of code-debt over the years.

This isn't code debt

[henon]

It is OK to disagree but please do it respectfully.

Here is my take. I think we'll postpone discussion on this because there are a lot of things planned for v7 that are much more important, I'll admit. We may still do it later as we decided that we'll have regular breaking releases in the future.

It is probably not much hussle for our users to make this change. A simple find and replace over the code base and it is done.

[Yomodo]

It is OK to disagree but please do it respectfully.

Apologies if I came across disrespectfully, certainly not my intention.

[henon]

No worries :)