Powershell: Naming convention for local constants

[xtqqczze]

Our coding guidelines the naming convention is to: "Use `PascalCase to name constant local variables and fields." and is common with dotnet repository guidelines.

On the other hand, the style for local constants is mostly camelCase in existing code so we should consider the logic for this part of our coding guidelines.

In https://github.com/PowerShell/PowerShell/pull/13217#discussion_r458263009 @rjmholt made a persuasive case we should use camelCase instead of PascalCase for local constants:

My thinking is that that's only for global constants (which behave most like value macros), rather than local constant variables (which can hold references and for which const indicates just immutability rather than referential transparency)

If we used camelCase for local constants this would be a violation of SA1303ConstFieldNamesMustBeginWithUpperCaseLetter but there is an open issue as to whether the rule should apply to local constants as well as fields.

[SeeminglyScience]

My thinking is that that's only for global constants (which behave most like value macros), rather than local constant variables (which can hold references and for which const indicates just immutability rather than referential transparency)

Does it? It still doesn't work with types that can't be embedded just like global constants. I was under the impression it was like method local functions in that it just limits scope syntactically but was more or less the same at the metadata level.

[rjmholt]

Looking into it, it sounds like I'm wrong and that const means the same thing everywhere. I personally prefer camelCase locals, but I don't want to invest any time debating it, so happy to let the conversation proceed

[SeeminglyScience]

I personally prefer camelCase locals, but I don't want to invest any time debating it, so happy to let the conversation proceed

FYI I was just making sure that was known, as long as the style is consistent it doesn't matter to me much.

[vexx32]

I think I also prefer camelCase locals, even if they're constant.

[iSazonov]

Our coding guidelines the naming convention is to: "Use `PascalCase to name constant local variables and fields." and is common with dotnet repository guidelines.

Makes no sense to change our guidelines. And we always follow .Net team code conventions.

On the other hand, the style for local constants is mostly camelCase in existing code so we should consider the logic for this part of our coding guidelines.

No, I did search in our code base - most consts are in PascalCase. Rest we should fix.

[vexx32]

@iSazonov the distinction being made is "constants" vs "local constants". Are we confident that most local constants are using PascalCase currently?

[iSazonov]

@vexx32 Yes, I mean local constants.

[xtqqczze]

Compare ^\s+const [^ ]+ [a-z] with ^\s+const [^ ]+ [A-Z].

It seems the majority of local constants begin with a lower case character.

[SeeminglyScience]

Looks pretty even to me (remember to only look at *.cs and enable match case if doing it from VSCode). Slightly more are lowercase.

[vexx32]

I guess we should take a vote then? 😛

[xtqqczze]

I think we should follow the same convention as https://github.com/dotnet/runtime Perhaps a case could be made for change there?

For the time being we could follow the style of the surrounding code. In this case we should disable the SA1303ConstFieldNamesMustBeginWithUpperCaseLetter StyleCop rule.

GitHub

dotnet/runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps. - dotnet/runtime

[rjmholt]

Thinking on my preference, I think it's because I rely on variable names to see their scope/lifetime.

Here's my current heuristic:

• camelCase: local
• _startsWithUnderscore: private field
• s_startsWithSUnderscore: private static field
• t_startsWithTUnderscore: private thread-static field
• PascalCase: property or constant (something that's either public, or would be safe to be public)

Naturally naming schemes like this are unpopular thanks to things like Hungarian notation polluting C[++] variable names everywhere, but:

• This is relatively lightweight compared to lpszNameOfThing and is mostly already a convention we follow
• We also have a policy of obvious variable type declaration (i.e. no var when the RHS isn't explicit about the type)
• Many of us do a lot of code review on GitHub, which isn't an IDE and doesn't have Go to Definition

Whether a local variable/value is constant or not is something the compiler can check and tends not to be too material to how a method is implemented. But whether something is local vs a property is a very important distinction, and one the compiler can't check for errors in.