Repository navigation
Type accelerators casing #54
Description
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?
Activity
rkeithhill commentedon Apr 19, 2016
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 ifor the language supported types andDateTime now = DateTime.Now;for the rest.KirkMunro commentedon Apr 19, 2016
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:
jasnic02 commentedon Apr 19, 2016
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 commentedon Apr 19, 2016
@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 commentedon Apr 20, 2016
@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 commentedon Apr 27, 2016
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...