[refactor] [style] Simplify all `string.Format(CultureInfo.CurrentCulture, format, args)` to `string.Format(format, args)`

[travisclagrone]

Synopsis

This issue is a minor but extensive style refactoring proposal to replace all invocations of string.Format(IProvider, string, ...) where the provider is explicitly specified to be the literal CultureInfo.CurrentCulture with string.Format(string, ...).

The expected benefit is simpler, more readable code.

No Change In Behavior

This change will not alter any behavior, since the the string.Format method uses the current culture by default anyway if no provider is passed. As stated in the first sentence under the heading "String.Format Method > Remarks > Formatting and culture",

Generally, objects in the argument list are converted to their string representations by using the conventions of the current culture, which is returned by the CultureInfo.CurrentCulture property. You can control this behavior by calling one of the overloads of Format that includes a provider parameter.

Feedback

First, is the content/risk/benefit of this proposed style refactoring accurately characterized herein?

Second, if this proposal is reasonable, would it be acceptable for someone (e.g. me, @travis-c-lagrone) to submit a single PR resolving this proposal? Or would it be preferable to approach it gradually over the course of multiple PRs?

Third, part of my motivation for raising this issue is to better understand the reason (if any) why string.Format is so commonly invoked throughout the code base with the literal argument CultureInfo.CurrentCulture. So that if there is a reason (e.g. facilitate culture parameterization), I can better address it as I perform some deep spot refactoring for other issues these days.

[bergmeister]

Yes, I think that sounds reasonable to me. The majority of the codebase was written a long time ago by someone else so I cannot comment on the reason for it but usually Microsoft had certain standards in the past that people followed with some of them due to .Net (Core) not supporting certain features.
In this case, I think I'd be happy with your proposed change, what do you think @rjmholt?

As I see you are getting more active in this repo, let me know if you have any other questions/problems about local development/testing, etc or if you are looking for issues to be tackled, I am happy to give pointers. We also have a ScriptAnalyzer channel in the PowerShell Slack workspace, are you familiar with it or do you want to join it?

[travisclagrone]

As I see you are getting more active in this repo, let me know if you have any other questions/problems about local development/testing, etc or if you are looking for issues to be tackled, I am happy to give pointers. We also have a ScriptAnalyzer channel in the PowerShell Slack workspace, are you familiar with it or do you want to join it?

Thank you very much. I may take you up on that.

Regarding Slack, I am not currently a member of the PowerShell workspace, but I would like to join. The ScriptAnalyzer channel sounds like it could be quite useful for me to follow.

[bergmeister]

Ok, thanks for your work and efforts in advance, you can join the PowerShell Slack workspace here
http://slack.poshcode.org/

[rjmholt]

So that if there is a reason (e.g. facilitate culture parameterization), I can better address it as I perform some deep spot refactoring for other issues these days.

@JamesWTruher knows more about this than I, but:

• Messages are resources for internationalization purposes which has been a requirement in the past (and may be once again), but that work isn't planned any time soon
• string.Format defaults to CultureInfo.CurrentCulture in both .NET Core and FX when it's not specified (link)
• It seems unlikely you'd want anything other than the current culture, and configuring it to use some other culture isn't possible (or probably useful) today otherwise

So it seems like this is a wanted refactor