Line too long false positives for comment lines with large URLs or Swagger annotations

Clean Code Report False-positive / False-negative...
1

For the line to long rules (go, python, but pretty much any language), Sonar will trigger issues for lines that should not be split up.

For example we have comments that point to long urls, splitting them up would make then no longer clickable or easy to copy/paste:

# http://example.com/some/very/long/url/with#query-tags-that-go-over-the-line-limit

For go-swagger annotations they are comments that are not splittable:

// UpdateUserConfig swagger:route PUT /user/configs/{config_id} User--Config internal r-user-configs v-v1 update-user-config

See:
https://goswagger.io/use/spec/route.html
https://goswagger.io/use/spec.html

2

Hi,

Thanks for the report. I guess the heuristic you would suggest is that no issue should be reported on lines without spaces? Although that wouldn’t work for your second example, which seems imminently split-able to me…

 
Ann

3

In the first example it would be lines where the content starts with http:// or https:// and then no spaces. Other url schemes could be included such as git+https://, ftp://, s3://, etc…

The second example is not splittable, since swagger would not be able to parse them, these are machine processed and not intended for humans.

If the line too long pattern could have an option to override for some comment lines based on a pattern then this would prove flexible enough that anyone with machine instructions embedded in comments would be able to silence the false positives.

Some sonar properties such as:

python.allowed-long-comments='\s+https?://[^ ]+$'
go.allowed-long-comments='\s+(https?://[^ ]+|\w+\sswagger:\w+\ .*)$'

If a long line is detected in a comment, but the content matches the patterns then the issue would be ignored. Since these should be infrequent it should have minimal performance impact on the rules processing.