Add section on variable style about powershellpracticeandstyle HOT 7 CLOSED

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 ;-)

from powershellpracticeandstyle.

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.

from powershellpracticeandstyle.

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?

from powershellpracticeandstyle.

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

from powershellpracticeandstyle.

from powershellpracticeandstyle.

from powershellpracticeandstyle.

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.

from powershellpracticeandstyle.