disallowMultipleLineBreaks: New configuration values

[dharkness]

Our main JS file contains multiple groups of related functions, but each too small to break out into separate files. We separate the groups using double blank lines with a comment header. These obviously get flagged, but I have two solution ideas:

1. Allow a number to denote the maximum number of line breaks. In our case that would be 3. The downside is that it allows this all over the place.
2. Add configuration option { "allowBeforeComment": true } or some better name. This would allow multiple line breaks if they immediately precede a comment.

[markelog]

{ "allowBeforeComment": true }

allExcept: ['beforeComment'].

Feel free to send a pr

[Nargonath]

@dharkness Are you working on a PR?

[dharkness]

@Nargonath No, I was starting by submitting bugs and feature requests while checking out JSCS. :) If I can put some time into it I'll let you know before I start. Otherwise feel free to take it.

[Nargonath]

@dharkness Alright fair enough. I'll work on it then. Thanks :) If I'm too long providing it feel free to go for it.

[Nargonath]

Should I put no limit of line breaks if they precede a comment or add a parameter for it?

[dharkness]

@Nargonath Ideally it would have its own parameter as unlimited is decidedly uncool. ;) But I don't know how you'd specify that given @markelog's desire to use allExcept: ['beforeComment'].

I've been thinking about this more, and the main problem is that we don't want to allow multiple blank lines before JSDoc comments--just these funky separators. But now it starts getting a bit extreme to have a setting for each type of construct that could follow.

What do you think would work best?

[Nargonath]

@dharkness Regarding the limit parameter I have no clue as well, I'll have to work it out.

What type of comment do you use as separators? Something like below?

function doStuff() {

}

/////////////////////////////////////////////////////////////////////

function doOtherStuff() {

}

I don't know if Esprima parses different comment types. As I have grasp so far you have access to token.isComment but I don't know if it can be more granular. If not, I think it could be added during the tokens tree building as a sub-property however I'm not sure that it would be a desired feature. We would have to ask to the maintainers.

[dharkness]

@Nargonath Yes, a // line comment. Of course, just to complicate things I don't want to allow the extra space before all line comments.

How about a line prefix instead? This would allow extra space before nearly any type of line you can think of. Do you get the raw line input, or is it a parsed token string? Even if the latter, as long as you get the comment text it could work. An array of prefixes and/or regular expressions would give a lot of flexibility.

[Nargonath]

@dharkness I'm not sure that you have access to the line input be it parsed or raw. I'm going too look what we have at hand.

[Nargonath]

@dharkness Well in the rule check() method you have access to the lines array and in the token you have access to the line and column coordinate. It would be possible to check the beginning of a comment to see if it contains the prefix. So you'd want to have prefixes/regular expressions that match the comment line where you want the exception to be taken into account?

[Nargonath]

After talking with @hzoo and @markelog, we agreed that unlimited line breaks before comments would be worthless. Your suggestion of adding parameters for number of line breaks and regexp is definitely better. We think however that the need behind this new behavior is too specific to your projects, hence it would be better suited as a project rule rather than a global modification of the library.

If you want to go down this road, here is an example that could be useful.

The issue will be closed but feel free to comment if you disagree or would like to add something. Discussions are always welcome.

[dharkness]

@Nargonath I fully agree, and in fact this is used in only one of our files as it is the global module that provides commonly used helpers that are too varied to break into their own modules.

At first it seemed more useful (I've seen it done in countless languages over the decades), but honestly I think of it as a bit of an anti-pattern.

That being said, love the code you have, right? Thanks for your help, and I'll take a look at your link. Cheers!

[Nargonath]

@dharkness You are welcome. Your suggestion helped me to improve my comprehension of the lib. Have a good evening/day. ;)