Adding examples to documentation of each linter

[IndrajeetPatil]

I think docs for each linter should have an examples section with at least one example of code that does produce lint and another that doesn't.

I think the style guide is good to provide the underlying rationale for the lint (provided that the reader actually clicks on that link!), but it doesn't lead to much exploration on the reader's part. Giving concrete examples means that the reader can just copy-paste examples and start toying around with them to see what does and doesn't lint.

Note to self: Make sure all of them follow the style guide, and so use " instead of ', e.g.

Progress tracker

• absolute_path_linter
• any_duplicated_linter
• any_is_na_linter
• assignment_linter
• backport_linter
• boolean_arithmetic_linter
• brace_linter
• class_equals_linter
• commas_linter
• commented_code_linter
• condition_message_linter
• conjunct_test_linter
• consecutive_stopifnot_linter
• cyclocomp_linter
• duplicate_argument_linter
• equals_na_linter
• expect_comparison_linter
• expect_identical_linter
• expect_length_linter
• expect_named_linter
• expect_not_linter
• expect_null_linter
• expect_s3_class_linter
• expect_s4_class_linter
• expect_true_false_linter
• expect_type_linter
• extraction_operator_linter
• fixed_regex_linter
• function_argument_linter
• function_left_parentheses_linter
• function_return_linter
• ifelse_censor_linter
• implicit_integer_linter
• infix_spaces_linter
• inner_combine_linter
• lengths_linter
• line_length_linter
• literal_coercion_linter
• missing_argument_linter
• missing_package_linter
• namespace_linter
• nested_ifelse_linter
• no_tab_linter
• nonportable_path_linter
• numeric_leading_zero_linter
• object_length_linter
• object_name_linter
• object_usage_linter
• outer_negation_linter
• package_hooks_linter
• paren_body_linter
• paste_linter
• pipe_call_linter
• pipe_continuation_linter
• redundant_equals_linter
• redundant_ifelse_linter
• regex_subset_linter
• semicolon_linter
• seq_linter
• single_quotes_linter
• spaces_inside_linter
• spaces_left_parentheses_linter
• sprintf_linter
• string_boundary_linter
• strings_as_factors_linter
• system_file_linter
• T_and_F_symbol_linter
• todo_comment_linter
• trailing_blank_lines_linter
• trailing_whitespace_linter
• undesirable_function_linter
• undesirable_operator_linter
• unnecessary_lambda_linter
• unneeded_concatenation_linter
• unreachable_code_linter
• unused_import_linter
• vector_logic_linter
• yoda_test_linter

[IndrajeetPatil]

Need to wait for #1480 to be merged before I can work on this.

[LukasWallrich]

This is a great idea. It would be ideal to also have a brief explanation/link for why that check happens - for instance, I do not understand why the extraction_operator_linter wants to see [[ rather than $, and can't find details on that in any style guide ...

[IndrajeetPatil]

@LukasWallrich Have a look at the new docs. Hopefully, it's clear why the recommendation is so.

[MichaelChirico]

Please don't forget to add a NEWS item of this when it's done :)

[IndrajeetPatil]

Will do! :)

[LukasWallrich]

@LukasWallrich Have a look at the new docs. Hopefully, it's clear why the recommendation is so.

Very helpful explanation, thanks. However, given that For data frames (and tibbles), irrespective of the size, the [[ operator is slower than $ and that it does not seem to have any advantage for tibbles, I find the unambiguous recommendation a bit odd ... but I guess linting has to be opinionated about trade-offs and emphasize consistency ...

[MichaelChirico]

Hi @LukasWallrich, not that extraction_operator_linter() is not a default linter, so it's not really a "recommendation". In fact we don't enforce this on ourselves:

https://github.com/r-lib/lintr/blob/main/.lintr_new

This is just an offered linter as some authors may prefer the robustness.

I'm also reminded of my SO question from long, long ago:

https://stackoverflow.com/q/29956250/3576984

While [[ is slower, it tends to be on the sub-millisecond scale. most authors should not be concerning themselves with the efficiency difference.

[IndrajeetPatil]

[MichaelChirico]

Thanks Indrajeet!!! 💪💪💪