Type accelerators casing

[jasnic02]

I love this project. I obsess over code formatting (not in a good way). Anyway, one thing I can't find mentioned is how to handle type accelerators with regards to casing and fully-qualified or not. For instance:

string or String or [System.String] ?

What I'm doing now is that for parameter declaration I use lowercase:
string$InputString

And:
$InputString -is string

but, I title case it when I am calling a method:

I have no idea why I chose that style and I'm not necessarily consistent with it across projects.

And, for those types that don't have an accelerator listed (System.Object, System.Math), I typically use either the title case or the fully qualified. Not sure why I treat them differently since [object] and [math] are certainly valid, I just do and blame MS for the lack of a listed accelerator for it (instead of blaming my OCD). sigh

Any thoughts/opinions on this one?

[rkeithhill]

Yeah I prefer lower case for built-in (accelerator) types e.g. [string], [switch], [bool], etc. But when specifying a full .NET typename, I tend to use the .NET casing e.g. [System.IO.Path]::Combine().

This is also what I do in C# e.g. string s, int i for the language supported types and DateTime now = DateTime.Now; for the rest.

[KirkMunro]

It's not quite that simple. We use type accelerators every day without realizing it: CmdletBinding, ValidateNotNullOrEmpty, etc are accelerators. Looking at the list of type accelerators that ship as part of PSv5, they all seem to follow this rule:

If the accelerator is for an attribute, then define the accelerator using PascalCase matching the attribute name with the trailing "Attribute" string removed.
Otherwise if the accelerator is for NullString, then define the accelerator using PascalCase.
Otherwise define the accelerator using lowercase.

The only outlier that does not follow those rules in the built-in type accelerators is PSTypeNameAttribute, but I believe that is special cased because PowerShell already had internal magic to make PSTypeName work. Either that or whoever created that accelerator simply didn't follow the rules. :)

As far as using accelerators vs .NET types, I would apply this rule:

1. If you are using an accelerator, then the casing used in the accelerator in PowerShell should be applied.
2. If you are creating an accelerator, then you should create it following the casing rules defined above.
3. If you are using a type that is inside of the System namespace that also has an accelerator to the same type that matches that type name, then you should use accelerator casing (e.g. [string], not [String])
4. If you are using a type that is not an accelerator then you should match the .NET casing of the namespace/type name as it was defined.

[jasnic02]

Thanks guys. This helps clear things up for me. Kirk, looking at your code in your *Px modules, you don't typically use accelerators? Is that merely personal preference, or is there more to it than that?

[rkeithhill]

@KirkMunro It's been a while since I have looked at the accelerator list but yeah I see what you're saying and agree 100%.

[KirkMunro]

@jasnic02 Short answer: it was a decision I made a long time ago when trying to adopt/define best practices to follow.

Longer answer: In modules I try to avoid shorthand, which includes command/parameter aliases, parameter prefixes, and it made sense to me to avoid type accelerators as well. I knew it would be unlikely for an accelerator to change or be removed (in fact you can't remove them in PSv5 due to a bug that isn't being considered for fix), but I decided back then to just stick with full type names as a rule in the modules I write. I suppose I should have realized I was using accelerators with the attributes I use in my modules, but I actually hadn't put that together in my head for some reason until this question came up today. I'm don't think I'm about to switch to using full names for attributes though, so I guess I should figure out if I want to start using accelerators elsewhere as well or not. :)

[ryanspletzer]

I like the rules @KirkMunro outlined above around casing for accelerators

As for using them at all, I've been going back and forth on whether to fully-qualify everything or use accelerators for modules I'm writing right now, and after trying out the fully-qualified approach I think I'm ready to go back to the accelerators. I think the PS team knows that if they removed one they would break a lot of stuff...