So, there was a useful post by @Jaykul on #17 that got lost amid some debates that were not relevant to that specific discussion. This just came up again for me while watching a live demonstration where I realized I really didn't like the capitalization guidelines they followed, so I thought I'd try to refocus the discussion on this since we never did come to a consensus.

Here is Jaykul's post on this (slightly modified to remove points of contention that derailed the other issue), copied so that you don't have to go look it up:

Since nobody else is going first, here are my thoughts. Any disagreement?

Keywords (try, catch, foreach, switch)
lowercase (rationale: no language other than VB uses mixed case keywords?)

Process Block Keywords (begin, process, end, dynamicparameter)
lowercase (same reason as above)

Comment Help Keywords (.Synopsis, .Example, etc)
PascalCase (rationale: readability)

Package/Module Names
PascalCase

Class Names
PascalCase

Exception Names (these are just classes in PowerShell)
PascalCase

Global Variable Names
$PascalCase

Local Variable Names
$camelCase (see for example: $args and $this)

Function Names
PascalCase

Function/method arguments
PascalCase

Private Function Names (in modules)
PascalCase

Constants
$PascalCase

I have doubts about Comment Help Keywords, and about is Constants.

Comment help keywords have frequently been written in ALLCAPS to make them stand out more (the same is true for the process block keywords) one need only search poshcode to see examples of this. Personally, I think that if the indentation rules are followed, all of these keywords would be indented one level less than everything else around them, so there is no reason to capitalize them to make them stand out.

Constants are basically global variables which should not be changed. Hypothetically we can enforce non-changing on them. Note that Microsoft has several such constants and follows NO CONVENTION AT ALL: $Error, $ExecutionContext, $PID, $PSVersionTable, $ShellId, $Host, $PSHOME, $true, $false

I would argue that true and false are special, and that other than that, these are all PascalCase except $PSHOME which obviously should be $PSHome 😉 -- Hypothetically I'd be willing to use some other naming convention (like $ALL_CAPS or $Under_Score) but they would forever clash with the constants Microsoft has created ;-)

I am 100% in agreement with all of this (now that I took the distracting parts out 😉).

The only place where I have any question here is around case sensitivity with acronyms, which was not called out. According to the Microsoft standard for PascalCase and camelCase, if an acronym is two letters then you don't change the case, but if it is three or more then you do. That results in command names that look like this:

Get-AzureVMDscExtension
Get-AzureVMDscExtensionStatus
Publish-AzureVMDscConfiguration
Remove-AzureVMDscExtension
Set-AzureVMDscExtension

My brain has a really hard time delineating between VM and Dsc in those command names. I always see VMD sc. Personally, I follow these same PascalCase/camelCase rules, but for acronyms I always put every character beyond the first as lowercase, to make the identifiers more readable. For example, I would have named all of the above commands like this:

Get-AzureVmDscExtension
Get-AzureVmDscExtensionStatus
Publish-AzureVmDscConfiguration
Remove-AzureVmDscExtension
Set-AzureVmDscExtension

If I was to place an exception on anything related to acronyms, it would be PS, because, well, PowerShell. Either that or I would modify Microsoft's rule, indicating that you only maintain case on an acronym if the acronym is 2 characters long, and when maintaining case any acronyms immediately after that one must use the same case. With that, the commands would instead look like this:

Get-AzureVMDSCExtension
Get-AzureVMDSCExtensionStatus
Publish-AzureVMDSCConfiguration
Remove-AzureVMDSCExtension
Set-AzureVMDSCExtension

There are examples of this in native PowerShell cmdlets as well, but for those examples, the acronym is at the beginning of the noun which seems easier to identify than when it is in the middle with mixed case acronyms side by side.

Anyway, we should explicitly decide how we want acronyms to be cased when using Pascal or Camel case. My vote would be to always make every character after the first in acronyms lowercase (like I show in the second example above), but I'll follow whatever the community decides, and I realize it would probably be best if we simply followed Microsoft's guidelines for consistency here (even if I don't like them).

So, to keep it simple, two questions:

1. Are there any objections to the proposed casing for the various PowerShell elements identified above?
2. Do you think we should follow Microsoft's guidelines for acronyms wrt Pascal and Camel case or is that some horrible Kool-Aid that we should throw away in favor of always lowercasing every character in every acronym beyond the first when applying Pascal or Camel case to these elements?