Add a linter to check spaces around colon(s)

[yu-iskw]

According to the style guide, :, :: and ::: don’t need spaces around them. It would be nice to have a linter about spaces around colon(s). http://adv-r.had.co.nz/Style.html

[jimhester]

Have you ever encountered this style in code in the wild? I never have...

[yu-iskw]

Indeed, there are rare cases to encounter to the style. However, it is important to check it fully.

[MichaelChirico]

I could imagine this as being part of the infix_spaces_linter -- the linter checks that low-precedence linters do have spaces, and high-precedence linters do not.

Adding 'help wanted' for now -- it should be doable to read the existing infix_spaces_linter code and extend it to this opposite case.

[AshesITR]

These operators are high-precedence: ,, ^, @, !, :, ::, :::, {, [, [[, (, ?, $ Of these, some should allow for spaces (or line breaks). I think we should lint !, :, ::, ::: and ? if they have space around them. All others can sometimes be used with whitespace, e.g.

a$very$
  long$
  chain$
  of_list_accesses@
  or_slot_accesses

(1 + 3) ^ 2

[MichaelChirico]

Should we just consider "infix-then-linebreak" OK in all cases? Would be easier to implement. Isolating ! and the others feels like a bit of a judgment call -- I agree with the choices at a glance, but it doesn't feel very principled.

[AshesITR]

NB :: and ::: produce parse errors when confronted with a line break. From the tidyverse styleguide I'd say linebreaks are not ok for !, since they aren't ok for !! either.

Actually:

::, :::, $, @, [, [[, ^, unary -, unary +, and :

should never be surrounded by spaces according to the style guide. I'd argue that we can make a conscious exception for indexing operators regarding line breaks, because it's sometimes necessary to fulfill line length requirements and implement the rules as written for all others.

[MichaelChirico]

I don't think x[\n is a violation of the style guide -- it's not surrounded by spaces, it just has a space on one side.

So I am leaning towards: always allow ${NON_WHITESPACE}${OP}${NEWLINE} for binary operators. In other words <expr> can't start with an operator and then be immediately followed by newline -- a non-operator part of the <expr> has to show up on the first line.

[AshesITR]

Well, x[ 1 only has space on one side as well.

I agree with your proposal for all binary operators except : (:: and ::: won't parse with a following newline anyway)

1:
  some_long_code()

is less readable to me than

1:(
  some_long_code()
)

if that line break is really necessary.

[MichaelChirico]

Have you ever encountered this style in code in the wild? I never have...

As to whether such code exists... yes it's not too hard to find:

https://github.com/palantir/spark/blob/b605c1b81d2ff75cd917fa067dd72dc3f0d6e6d2/R/pkg/R/utils.R#L660-L665