Help collaborate on lintr!

[jimhester]

As announced at https://twitter.com/jimhester_/status/997109466674819074 I am interested in having some help working on lintr. This issue can serve as a place for those interested to 'sign up' and also to discuss priorities. So reply below if you are interested and I will invite you to be a collaborator on the project.

[jimhester]

How (I hope) this will work

Everyone who replies to this issue will be invited to be collaborators on the lintr project.

What exactly happens if I accept? Does it mean I’ll break everything if I click the wrong button?

Concretely, if you accept the invitation, this does these things:

• It lets you manage incoming issues on by labelling them, closing them, etc.
• It lets you merge pull requests by clicking Github’s big green “Merge” button, but only if all their tests have passed.
• It automatically subscribes you to notifications (but you can unsubscribe again if you want through the Github interface)
• It does not allow you to push changes directly to Github without submitting a PR, and it doesn’t let you merge broken PRs – this is enforced through Github’s “branch protection” feature, and it applies to everyone from the newest contributor up to the project founder.

Okay, that’s what I CAN do, but what SHOULD I do?

Short answer: whatever you feel comfortable with.

We do have one rule, which is the same one most F/OSS projects use: don’t merge your own PRs. We find that having another person look at each PR leads to better quality. (Exception: you may see @jimhester merging his own PRs. This happens because he is lonely and has no-one to review them for him. It would make him happy if you reviewed and – if they look good – merged his PRs.)

Beyond that, it all comes down to what you feel up to. If you don’t feel like you know enough to review a complex code change, then you don’t have to – you can just look it over and make some comments, even if you don’t feel up to making the final merge/no-merge decision. Or you can just stick to merging doc fixes and adding tags to issues, that’s very helpful too. If after hanging around for a while you start to feel like you have better handle on how things work and want to start doing more, that’s excellent; if it doesn’t happen, that’s fine too.

If at any point you’re unsure about whether doing something would be appropriate, feel free to ask (by posting Github comment). For example, it’s totally OK if the first time you review a PR, you want someone else to check over your work before you hit the merge button.

(adapted from https://trio.readthedocs.io/en/latest/contributing.html#joining-the-team)

Tasks to perform

• - Triage all open issues, using the tidyverse labels. Each issue should have at least one label.
• - Review open pull requests, seeing if they can be adapted or should just be closed.
• - Assess performance of the devel version vs that of the current CRAN version (devel is quite a bit slower)
• - Get devel version in a state where we can have a new CRAN release.
• - Consider feasibility of converting existing linters to using XPath expressions rather than R code (this is advanced, but could make things much faster) Object name linter performance improvements #236 is an example

[gdequeiroz]

Gabriela de Queiroz

[MHenderson]

I would like to help.

[brankokovac]

Branko Kovac

[JamesCuster]

I am interested in helping out.

[jimhester]

So do you all think it would be helpful to have a gitter chat room so you could have more real time access for questions etc, or are GitHub comments enough?

Ok added one https://gitter.im/jimhester-lintr/Lobby

[erleholgersen]

I'm also interested in helping out.

[stufield]

Hi Jim,
Love what you've started with lintr and would be happy to be involved to the extent I can contribute.
Stu

[navdeep-G]

I am interested if there is still room. :)

[adanvr]

I would like to help as well

[dougmet]

Hi, a few of us from Mango might be able to muck in as it slots together quite well with mangothecat/goodpractice and friends. cc @hfrick @sellorm @owenjonesuob

We use lintr heavily on lots of packages as part of ValidR (via mangothecat/packageMetrics2)

[jimhester]

@dougmet, that would be great, If the other Mango folks are interested please add a separate reply and I can add you to the collaborators.

[jimhester]

Also most of the linters in goodpractice that would be great to have in lintr, so a good first contribution would be doing that!

[wligtenberg]

I am interested in helping out as well.

[randy3k]

I am the author of https://github.com/REditorSupport/languageserver
I’d also like to be a collaborator.

[hfrick]

Hi @jimhester, some lintr/goodpractice crossover would be nice. 👋

[chucheria]

I want to help too! 🙌

[owenjonesuob]

Hiya, great to see interest in lintr-goodpractice collaboration! I'm definitely keen to help out.

[chauhraj]

I am late to the party but would like to help too. I hope I am not too late to join.

[grahamrp]

I'm also keen to help.

[jimhester]

Never too late!

[dragosmg]

Same here. I'd be keen to help.

[cryptomanic]

I would love to contribute.

[gu-stat]

I'd like to help, if there's still room.

[jimhester]

A great first issue PR for someone to review would be #321, it mainly needs a note added to NEWS.md

[gdequeiroz]

Hi @jimhester, what do you mean by "assess performance" in Assess performance of the devel version vs that of the current CRAN version (devel is quite a bit slower)

[jimhester]

Measure how badly the performance has degraded and if possible which linters are most responsible for the degradation.

Ideally with something like profvis but as a start even using system.time() with a large R file that would have many lints, check.R in the tools package is an extreme case.

download.file("https://raw.githubusercontent.com/wch/r-source/3ddb337d62817599d3cb739c8815bf2276e01511/src/library/tools/R/check.R", "check.R")
system.time(lints <- lintr::lint("check.R", cache = FALSE))

On my machine this takes ~60-70 seconds with the current CRAN version, the devel version takes about 9 minutes.

So you will likely need to use a smaller file to narrow down the exact causes, but good first step is identifying the extent of the problem.

[jimhester]

It would be great for someone to review #326

[jabranham]

We can measure the speed difference between various linters by looping over the defaults:

library(lintr)
x <- list(length = length(names(lintr::default_linters)))
i <- 1
for (name in lintr::default_linters){
  x[[i]] <- system.time(
    lint("check.R",
         linters = name,
         cache = FALSE))
  names(x)[i] <- names(lintr::default_linters[i])
  i <- i + 1
}

comparing the CRAN and github versions I get the following speeds:

                                   CRAN      GH
assignment_linter                 6.796   7.905
single_quotes_linter              7.633   8.772
absolute_paths_linter             9.637      NA
no_tab_linter                     8.007   9.637
line_length_linter                6.743   7.937
commas_linter                     8.745  10.155
infix_spaces_linter               8.687   9.975
spaces_left_parentheses_linter    9.251  10.608
spaces_inside_linter              7.862   9.471
open_curly_linter                 7.107   8.612
closed_curly_linter               7.077   8.572
camel_case_linter                33.693      NA
multiple_dots_linter              9.081      NA
object_length_linter              8.342 196.771
object_usage_linter              11.742  13.594
trailing_whitespace_linter        8.132   9.175
trailing_blank_lines_linter       6.588   7.903
commented_code_linter             8.349   8.495
function_left_parentheses_linter     NA  10.796
object_name_linter                   NA 196.275
pipe_continuation_linter             NA  75.777

So it looks to me that the three linters responsible for the slowdown are object_name_linter, object_length_linter, and pipe_continuation_linter. Those could just be removed from the defaults, if a CRAN release is planned soon.

[russHyde]

Happy to pitch-in if you still need helpers.
Russ Hyde, Glasgow Uni.

[Neil-Schneider]

Hi Jim, I would love to join the team.

[mjsteinbaugh]

@jimhester I'm up for adding some linters that help adhere to the Bioconductor coding style.

Also, is there an easy way to get S3 methods to pass linter checks (e.g. function.default will warn about the period).

[jameslamb]

As far as I could tell from #348 , this is the place to kindly request a new release to CRAN. The discussion on #348 predates v1.0.3, which was released in November 2018.

Could you please prepare another release to CRAN?

I'd like to take advantage of these linters in projects that require building from package managers (not GitHub):

github_only_linters <- list(
    "equals_na" = lintr::equals_na_linter
    , "function_left" = lintr::function_left_parentheses_linter
    , "implicit_integers" = lintr::implicit_integer_linter
    , "paren_brace_linter" = lintr::paren_brace_linter
    , "semiconlon" = lintr::semicolon_terminator_linter
    , "seq" = lintr::seq_linter
    , "todo_comments" = lintr::todo_comment_linter
    , "true_false" = lintr::T_and_F_symbol_linter
)

Thanks very much!

[joaopmatias]

Hi, I'd like to contribute, too!

[renkun-ken]

I'd like to contribute more, thanks!

[MichaelChirico]

I think this is safe to close; feel free to re-open