Repository navigation
Maximum line length indicator #30
Description
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.
Activity
Jaykul commentedon May 30, 2015
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 commentedon May 30, 2015
I'm ok with it being an optional thing and not a must
Sent from my iPhone
dlwyatt commentedon Jun 2, 2015
Works for me as well.
hdansou commentedon Jun 18, 2015
@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 commentedon Jul 11, 2015
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 commentedon Jul 11, 2015
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 commentedon Jan 6, 2016
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:
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.
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 commentedon Apr 3, 2016
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 commentedon Apr 4, 2016
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)