Maximum line length indicator

[dlwyatt]

Does anyone know of an add-on for the ISE that will display an indicator of some sort on a specified column? Without that, I don't think it's a good idea to include a maximum line length item in the style guide. While other editors such as Sublime Text offer this, the ISE is pretty much the de facto script editor for the majority of the PowerShell community.

Sure, you can look for the tiny "Line #, Col #" text in the status bar, but it's annoying to have to constantly shift your eyes down there to know whether you've crossed the boundary.

[Jaykul]

Considering I can resize text with the mousewheel in all my code editors, and can scroll side-to-side with the tilt-wheel on my mouse, and that I have a 24" monitor, I'm ok leaving line length out completely.

It might be better to just word it as: we suggest you shouldn't care about line length since ISE can't show a column line anyway -- but if you do, to please consider using ...

Is that good enough, @dlwyatt? Anyone opposed? @darkoperator - did this actually matter to you? I know you had a much shorter limit written originally.

[darkoperator]

I'm ok with it being an optional thing and not a must

Sent from my iPhone

On May 30, 2015, at 1:34 AM, Joel Bennett notifications@github.com wrote:

Considering I can resize text with the mousewheel in all my code editors, and can scroll side-to-side with the tilt-wheel on my mouse, and that I have a 24" monitor, I'm ok leaving line length out completely.

It might be better to just word it as: we suggest you shouldn't care about line length since ISE can't show a column line anyway -- but if you do, to please consider using ...

Is that good enough, @dlwyatt? Anyone opposed? @darkoperator - did this actually matter to you? I know you had a much shorter limit written originally.

—
Reply to this email directly or view it on GitHub.

[dlwyatt]

Works for me as well.

[hdansou]

@Jaykul When you move your code away from your 24" to github, others will have hard time reading through it. I suggest a maximum line length is included in the style guide.
I work with a 27" monitor but I try to keep my line length at 110 which is readable on github or any small monitor.
@dlwyatt I have not found an add-in yet that can do it and I hope to see one soon.

[dlwyatt]

IseSteroids just added this option in the 2.2.0.5 beta. It's not a free add-on, but IMO well worth the money for people who are writing PowerShell code professionally and like to use the ISE.

[hdansou]

Perfect! I updated ISESteroids and it works as expected.
👍 I do not regret buying the license.
In the style guide, the recommended line length could be up to 120 to match GitHub.

[ryanspletzer]

I've actually been trying to stick to this rule lately. Knowing where the columns are at isn't too bad with other editors (ex. PS tools for VS), but I still find this rule pretty constricting to stick to at times.

When lines get too long because of parameters I'm doing a lot of:

$splat = @{
    param1 = "this"
    param2 = "that"
}
Do-Thing @splat

I'm also doing the whole multi-line string-wrapping thing for long strings. And although these techniques keep the line lengths shorter, keeping it to 115 or 116 it really hurts readability of the code...

Sidenote: I get much more value out of splatting when I need to generate dynamic sets of parameters to functions I call based on parameters passed into my current function, i.e.

$splat = @{
    RequiredStringParam = $StringParam
}
if ($SwitchParam.IsPresent) {
    $splat.Add('AnotherSwitchParam', $true)
}
if (-not [String]::IsNullOrWhiteSpace($OptionalStringParam)) {
    $splat.Add('AnotherStringParam', $OptionalStringParam)
}
Do-Thing @splat

Is it that prevalent on GitHub for lots of projects to follow those strict line length rules? I don't see that too much elsewhere, but curious what others think. (Also, wouldn't be too surprised if the GitHub site updates at some point down the road to responsively accommodate longer lines.)

Beyond the GitHub thing, keeping line lengths to 115/116 for purposes of the console I don't think is that valuable, especially because depending on monitor pixel density many folks change their font size to be smaller / larger to compensate.

I think it would be better as a recommendation / optional rule than a hard "must."

[JeNeSuisPasDave]

I find that a line length of 80 is best for all languages, Powershell included.

Why? Many of us work on laptops that don't have wide screens. Given a side bar that consumes a good chunk of horizontal space (in most IDEs, e.g. Visual Studio) or editors (e.g. Sublime Text 3), you have even less space that the resolution width would imply.

And my eyes aren't so great, so I use a larger font size.

For those on a wide enough display, an 80 character line length will often allow side-by-side panes or windows for editing source code.

If you look through the various Google style guides (for Python, C++, etc.) you'll typically see either 80 or 100 chars given as max line length. More than 100 is probably excessive, and really, 80 is the most flexible.

I've been using 80 chars as my line length limit for a long time -- and doing so for Bash, Python, C/C++, C#, Fortran (yep), and now for Powershell. I've had no problems doing so, and I use descriptive variable and class names.

Once you get used to splitting and continuing statements, it becomes second nature and doesn't get in the way of code authoring at all.

I'd like to see a recommendation of 80 for line length. Either that, or no recommendation at all.

Bottom line: the tradeoff is that the shorter the line length the more devices and environments in which the code can be cleanly viewed and edited, and the shorter the line length the more often lines will need to be split and continued. I make that trade-off more strongly in favor of being friendly to more devices and environments.

[KirkMunro]

IMHO, recommending 80 as the max line width is like recommending 1024x768 as the recommended desktop resolution. Widescreen monitors/screens = better support for longer lines, even with larger fonts. Plus, PowerShell is a verbose language where descriptive variable names and command names is encouraged.

Some modules have very large command sets, and very long names to clearly identify command intent within those command sets. Take AzureRM, for example -- it's not the poster boy we want for PowerShell right now, but looking at all commands on my system and identifying the top 10 in terms of command length, and every command in that top 10 comes from some Azure module (AzureRM.NotificationHubs, AzureRM.Sql, Azure, AzureRM.OperationalInsights, AzureRM.SiteRecovery. The longest command name, Remove-AzureRmNotificationHubsNamespaceAuthorizationRules, is 57 characters long. Place that inside of a function that properly indents and wraps inside of a begin, process, or end block with a try/catch {$PSCmdlet.ThrowTerminatingError($_)} and right off the bat you're at 69 characters, and that's without using any parameters or assigning results to a variable or placing the call in a condition or loop statement. In other .NET languages like C# you might have something along the lines of AzureRm.NotificationHubs.NamespaceAuthorizationRules.Remove(...) that could be split across multiple lines at the dot reference operator, but unfortunately not in PowerShell. This is an extreme example, but it is a good one because it highlights that a short recommended line length is appropriate in a language with more tokenizable command names, but in a language with very long command names where verbosity is encouraged, 80 characters is simply too short.

All that said, I wouldn't personally back a recommendation for anything less than 110 characters as the recommended line length, and my preference would be for 120 characters (which is a value that I think makes much more sense given the default buffer width in the PowerShell console is 120 characters)