PowerShellPracticeAndStyle icon indicating copy to clipboard operation
PowerShellPracticeAndStyle copied to clipboard

Add section on variable style

Open eodeluga opened this issue 8 years ago • 7 comments

It may be in general guidelines, but I could not find a general guideline on defining variables and I think there should be a section for this.

Is it best to use camelCase? Is it best to UpperCase each word?

What is the general community view?

eodeluga avatar Jul 06 '16 15:07 eodeluga

i do UpperCaseEachWord for parameters for functions, and lowerCamelCase for variables inside functions.

dotps1 avatar Jul 06 '16 15:07 dotps1

Yep, I agree with that. In general, camelCase for variables, but PascalCase for parameter names because parameters are expected to be PascalCase and it affects tab-completion/intellisense, etc.

I'm not sure the style guide needs to specify a preference for capitalization though, apart from function names and parameters -- although I will admit I have a strong preference for $camelCase vs $python_style_separated_words ;-)

Jaykul avatar Jul 06 '16 20:07 Jaykul

I tend to use PascalCase everywhere, mainly because it looks more formal. Also, if I define a parameter with PascalCase, tab-completion copies that in the body of the function so that's generally what I stick with.

@Jaykul do you have any arguments for a certain style, like camelCase? I've seen some who attempt to differentiate variable scope with casing, but it seems too complex and delicate to support.

mattmcnabb avatar Jul 07 '16 02:07 mattmcnabb

I tend to use PascalCase everywhere as well. Is there more than just previous language experience that would make camelCase better?

gerane avatar Jul 07 '16 03:07 gerane

@jaykul I agree about the Python style variables. I've never liked those personally.

gerane avatar Jul 07 '16 03:07 gerane

I don't think there are any arguments for certain styles that can't be countered. Clearly it's "easier" to type lower case letters, but $variable vs $Variable is hard to argue considering that leading $ ...

The fact is that the built-in variables are also all over the map. Most people tend to use all upper case for "constants" but PowerShell uses all lower case: $null, $true, $false, $args, $input ... and then sometimes uses upper case: $PID, $HOME, $PSHOME, $PWD and $LASTEXITCODE ... but all the preference variables are PascalCase: $ConfirmPreference, $DebugPreference, $ErrorActionPreference, $InformationPreference, $MaximumAliasCount, $MaximumDriveCount, $MaximumErrorCount, $MaximumFunctionCount, $MaximumHistoryCount, $MaximumVariableCount, $ProgressPreference, $PSBoundParameters, $PSCommandPath, $PSCulture, $PSDefaultParameterValues, $PSEdition, $PSEmailServer, $PSScriptRoot, $PSSessionApplicationName, $PSSessionConfigurationName, $PSSessionOption, $PSUICulture, $PSVersionTable, $VerbosePreference, $WarningPreference, $WhatIfPreference .....

And then there's $PROFILE in powershell.exe, but $profile in ISE?

Jaykul avatar Jul 07 '16 05:07 Jaykul

Is there more than just previous language experience that would make camelCase better?

Probably not but for us C# devs, it's hard to shake. I still tend to use camelCase for local variables and PascalCase for everything else (parameters, script/global variables).

It might be better to ask the VB crowd about casing conventions for variables, since VB also has case-insensitive variable names IIRC. I suspect there probably should be a recommendation to use the same casing for a variable everywhere e.g. if I initialize $foo try to use $foo everywhere instead of $FOO or $Foo or $FoO.

rkeithhill avatar Jul 10 '16 18:07 rkeithhill