You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 $camelCasevs$python_style_separated_words ;-)
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.
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?
Reacted by Mikey Lombardi (He/Him) and Matt McNabb
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.
Activity
dotps1 commentedon Jul 6, 2016
i do UpperCaseEachWord for parameters for functions, and lowerCamelCase for variables inside functions.
Jaykul commentedon Jul 6, 2016
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
$camelCasevs$python_style_separated_words;-)mattmcnabb commentedon Jul 7, 2016
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.
gerane commentedon Jul 7, 2016
gerane commentedon Jul 7, 2016
Jaykul commentedon Jul 7, 2016
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
$variablevs$Variableis 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,$PWDand$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
$PROFILEin powershell.exe, but$profilein ISE?rkeithhill commentedon Jul 10, 2016
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.