Stylecopanalyzers: Rule proposal: Line Length

[GregReddick]

I propose a rule limiting line length in files. There should be a setting with a default.This is what I wrote in my style guide (now published on Amazon):

Each line of code must be no more than 140 characters long. This length was chosen to allow printing of code using a Consolas 10 point typeface, using the landscape printing orientation on Letter (8 ½" x11") or A4 paper. While this is the recommended length, the programming team can standardize on any other length.

If the page header lines are 140 characters long, the code window easily can be sized to this width. Alternately, the Productivity Power Tools extension (a free download published by Microsoft) allows creating Column Guides that places a line at the proper location on the screen in the code window.

If a line is commented out with ////, then the line length is permitted to exceed the normal length by four characters, to allow for the comment characters. The comment characters presumably will be removed at some point, at which point the length will be correct.

The code fix is a little tricky, though, if we want the code to match all the other style rules after it completes. I'd be okay with just finding the previous white space or punctuation character to the limit and wrapping to the next line and indenting. Then other rules with their code fixes could be applied.

[sharwell]

This rule is equivalent to SP2100 which was referenced in #782.

My vote is :-1: on including this rule in StyleCop Analyzers. I find that strict line lengths frequently result in code review diffs being larger than otherwise required, which makes them more difficult to review. If the average code review tool was based more on semantic changes than changes to text within a line, then my vote might be different. However, at least today this is definitely not the case. Since code review process is both more common than and more important than the ability to print code without wrapping lines, my vote is placed in favor of allowing flexibility in line lengths where developers feel doing so will help reviews.

:memo: This rule has already been implemented in Menees.Analyzers. I do not know if this is already an open source project, but I would of course welcome the project to the DotNetAnalyzers organization if @bmenees was interested in that.

[GregReddick]

I think this should be a StyleCop rule. It fits with the other rules here. If the consensus is that it is initially disabled, I'm okay with that because it can be turned on.

It's not just about printing. It's about keeping the code on the screen without horizontal scrolling. I _hate_ horizontal scrolling, and I'm sure many others do too. With Roslyn, the ability to perform tests for semantic changes is much more viable. If this rule were in place, it would encourage the development of those rules.

[menees]

I agree with @GregReddick about horizontal scrolling. I hate it. I implemented a line length rule in Menees.Analyzers because I constantly do side-by-side diffs for code reviews and revision history checks in TFS. At home I use a line length of 160, and at work my team uses a line length of 180. So the line length rule has never been about printing for us. It's always been about minimizing the need for horizontal scrolling when doing side-by-side code diffs.

Menees.Analyzers is open sourced and Apache-licensed. It's not on GitHub because I use TFS online, and I needed the rules implemented quickly to speed VS 2015 adoption at my work (where we weren't willing to give up the functionality of the old StyleCopPlus rules). It's fine with me if some or all of the Menees.Analyzers code ends up in StyleCopAnalyzers; I can even relax the license if necessary.

[reasra]

I'm guessing this didn't go anywhere. Kind of disappointing, but I understand there are more important things. Would have loved it, even if it were disabled by default as suggested.

[pkess]

I just created a rule for this. Please have a look

[reasra]

Hey, thanks for the update! I've been on travel the last few weeks and have not had a chance to try this. I just checked out #2302 but I guess it got put on hold for some reason. Would love to test this, but the nuget prerelease 1.1.0-beta001 does not seem to include SA1140. Please let me know if I can help.

[pkess]

Hi, actually the commit is not yet available in a nuget package. You can clone the repository and build it on your local machine.
At the moment i don't have a windows pc to build a package for you.

[sharwell]

@pkess the package is attached to the AppVeyor build as an artifact. You can download it by following the link after the build completes for a pull request.

[pkess]

@sharwell i checked out AppVeyor for #2302 but the list of artifacts seems empty to me. Can you help?

[mclean25]

Any update on this? Would love to be able to use it.