Configuration for ProhibitUnusedVariable

[blueyed]

I would like to configure ProhibitUnusedVariable (which is not enabled by default currently) to ignore variables named _.

I could also imagine to make this the default.

Apart from that vimlint allows to configure this for specific variables:

    " @vimlint(EVL102, 1, l:true)
    …
    " @vimlint(EVL102, 0, l:true)

Configuration based on e.g. identifier.value does not appear to be possible with vint, is it?

[Kuniwak]

Sorry for my late reply.

I would like to configure ProhibitUnusedVariable (which is not enabled by default currently) to ignore variables named _.

It can be configured by policies.ProhibitUnusedVariable.ignored_patterns since v0.4a1. This is the example for ignoring _ and __ and so on:

---
policies:
  ProhibitUnusedVariable:
    enabled: yes
    ignored_patterns:
      - '^_+$'

But now it is not default option. Because I do not know whether the meaning of _ is widely agreed or not.

[blueyed]

Thanks a lot! The example pattern should be '^_' maybe (if added to docs) - it would match both _foo and just _.

[dbarnett]

Thanks for implementing this! I tried it out and it worked nicely.

I ignored the pattern '^unused.*' in my case. Would it be possible to configure that one as ignored by default? It's a pretty widely accepted convention, and anyway I would be awfully surprised if anyone complained that they were expecting to see warnings about unused variables named "unused".

Have you considered semantics for ignored_patterns configured at different levels (project, user, vint defaults)? If it overwrites the entire list then users who really want aggressive warnings for unused variables regardless of name can configure ignored_patterns: []. I could see project configs wanting a way to extend the user's ignore list instead of overriding it, though.

[Kuniwak]

The example pattern should be '^_' maybe (if added to docs) - it would match both _foo and just _.

@blueyed I think _foo might meant just private component. So, I used only _ and __ as the example.

[Kuniwak]

It's a pretty widely accepted convention

@dbarnett I have never seen it, so I interest the actual example. Could you provide the example that using unused.*?

[Kuniwak]

Have you considered semantics for ignored_patterns configured at different levels (project, user, vint defaults)? If it overwrites the entire list then users who really want aggressive warnings for unused variables regardless of name can configure ignored_patterns: []. I could see project configs wanting a way to extend the user's ignore list instead of overriding it, though.

Now, we cannot extend ignored_patterns by more local config, but it is not expected behavior. I feel good about extending array basically, but I worry about we cannot achieve removing ignored_patterns in locally by extending array. 🤔

Does anyone have an good idea?

[blueyed]

@Kuniwak

I think _foo might meant just private component. So, I used only _ and __ as the example.

Yes, "_" might be used, but I think Foo(_bar, _baz) is better than Foo(_, _) - since you can still see what the unused arg is (and it might even be not allowed to use _ twice.

[Kuniwak]

Yes, "_" might be used, but I think Foo(_bar, _baz) is better than Foo(_, _) - since you can still see what the unused arg is (and it might even be not allowed to use _ twice.

Ah, I see. I think we can avoid the problem by repeating _ like the folowing Foo(_, __, ___), but it is not readable way. I think the better approach may be creating only_function_args: true to ignored_patterns:

---
policies:
  ProhibitUnusedVariable:
    enabled: yes
    ignored_patterns:
      - pattern: '^_'
         only_function_args: yes

But I feel it is complex...

[dbarnett]

@dbarnett I have never seen it, so I interest the actual example. Could you provide the example that using unused.*?

AFAIK it's not that common for vimscript plugin authors to care about scrubbing unused variables (and false positives) from their projects yet so I wouldn't expect you'd see such conventions used much in vimscript projects in the wild. All the Google code checking tools I've used for different languages support unusedBlah or unused_blah, and you can find examples in Google projects, for instance the python def main(unused_argv) definitions like https://github.com/tensorflow/tensorflow/blob/f1f2fff2c149ea3a848ec61b7d3fcd39a6dc3f06/tensorflow/python/client/notebook.py#L53.

I'm using it in function! maktaba#syscall#async#HandleStdout(unused_channel, message) at https://github.com/google/vim-maktaba/blob/1e5f7e62d3bf7b9679b5e707fa925072214593d0/autoload/maktaba/syscall/async.vim#L50.

[blueyed]

only_function_args: true

Why? I think just using ^_ is fine. I am not really convinced about ^unused_ - but ^_|^unused_ would be fine for me - or ^(?:_|unused) (?: to not create an unnecessary group).

[blueyed]

only_function_args

I think it is good for let [bar, _] = list then already, too.

@dbarnett Woul you use let [bar, unused_seconditem] = list in this case?

[dbarnett]

@blueyed let [foo, _] = or let [foo, _bar] = is fine. As a project maintainer I prefer named unused_foo placeholders where it's reasonable, but I'd definitely vote for ^_|^unused because I don't see any reason an unused variable checker should complain in either of those cases and I'd expect to see both in the wild.

[Kuniwak]

@dbarnett Thanks. This actual example makes sense. I'm gonna add ^unused_ to the default.

Why? I think just using ^_ is fine.

@blueyed I worry that ignored_pattern: ^_ can make false-negatives as the following:

let _foo = "I'm a private variable and not used, but matched by ^_"

So, I think we should limit the variable type that ignored_pattern: '^_' applied. Then the variable type might be only function/lambda arguments because unuvoidable unused variables are typically function/lambda arguments.

[blueyed]

@Kuniwak

I worry that ignored_pattern: ^_ can make false-negatives

Oh, I see what you mean now. However private variables are not a thing in Vim really, are they?

I can imagine g:myplugin#_internal (should not be matched by ^_, or g:_something_internal (would get matched) though.