Unresolved reference: when error highlighting is too much

Ruby is a particularly dynamic language even amongst others of its kind, we get it. This offers us great flexibility but is also the source of many mistakes, and RubyMine helps us avoid these mistakes with intelligent source code analysis and error highlighting. That's good.

I have a firm belief, however, that RubyMine (or any other source code analysis tool, for that matter) should never throw a false positive. It's ok to miss some problems, but it's definitely not ok to highlight correct code as a problem. I need the confidence to know that if RubyMine is telling me something is wrong, I have to look at it -- I shouldn't ignore warnings.

Currently, RubyMine highlights way too many false positives. Most warnings in my project are in fact false positives, and I've reported numerous issues about it. Here's a few suggestions that I believe would greatly reduce the number of false positives, if not eliminate them:

  1. If RM can't infer the type of an object, don't highlight any messages sent to this object as an error/warning.
  2. If RM does know the object type, but this type has method_missing defined, don't highlight any messages sent to this object as an error/warning.
  3. The second rule could be tightened for a few classes with known method_missing patterns, like ActiveRecord::Base.


If RubyMine keep throwing all these false positives, the user is going to loose confidence, sooner or later. He will sooner or later loose the patience to look at all those warnings, and just ignore them. When this happens, RubyMine looses it's usefulness. Don't let this happen, please.

0
Avatar
Permanently deleted user

Marcus,

I agree with some of what you're saying, and I too have a lot of
frustration with RubyMine throwing false positives.

However, I think the answer lies less in adding more global rules, and
more in allowing the programmer to configure when certain inspections
apply, and when they do not.

The other editors, notably the javascript and html editors allow you to
suppress an inspection for a statement or a file, and I'd like to see
that for ruby as well.

I think this could be carried further though, and what I'd like to see
eventually is some way of telling rubymine about your metaprogramming
model, where it applies, and enable or disable (or add!) inspections
based on that.

Do to ruby's dynamic nature you are free to add semantics as you see fit
, but those semantics are still there, and there are still constructs
which are invalid within your new semantics. It would be nice if you
could somehow communicate to rubymine your new semantics and tell it
where those semantics apply, and what's valid and what's not within
those semantics.

I'm sure that's a tall order to implement, but it would be nice down the
road. In the short term, I think giving finer grained control over
inspections would alleviate a lot of the pain.

Anyway, I agree with your fundamental frustration. The inspections can
provide a lot of value, but as it stands, I don't trust them, and so my
eye just passes over them as if they weren't there at all.

cheers,
Charles

Marcus Brito wrote:

Ruby is a particularly dynamic language even amongst others of its kind, we get it. This offers us great flexibility but is also the source of many mistakes, and RubyMine helps us avoid these mistakes with intelligent source code analysis and error highlighting. That's good.

I have a firm belief, however, that RubyMine (or any other source code analysis tool, for that matter) should never throw a false positive. It's ok to miss some problems, but it's definitely not ok to highlight correct code as a problem. I need the confidence to know that if RubyMine is telling
me something is wrong, I have to look at it -- I shouldn't ignore warnings.

Currently, RubyMine highlights way too many false positives. Most warnings in my project are in fact false positives, and I've reported numerous issues about it. Here's a few suggestions that I believe would greatly reduce the number of false positives, if not eliminate them:

1. If RM can't infer the type of an object, don't highlight any messages sent to this object as an error/warning.
2. If RM does know the object type, but this type has method_missing defined, don't highlight any messages sent to this object as an error/warning.
3. The second rule could be tightened for a few classes with known method_missing patterns, like ActiveRecord::Base.

If RubyMine keep throwing all these false positives, the user is going to loose confidence, sooner or later. He will sooner or later loose the patience to look at all those warnings, and just ignore them. When this happens, RubyMine looses it's usefulness. Don't let this happen, please.

---
Original message URL: http://www.jetbrains.net/devnet/message/5236976#5236976

0
Avatar
Permanently deleted user

Hello Marcus,

Ruby is a particularly dynamic language even amongst others of its kind, we get it. This offers us great flexibility but is also the source of many mistakes, and RubyMine helps us avoid these mistakes with intelligent source code analysis and error highlighting. That's good.


I have a firm belief, however, that RubyMine (or any other source code analysis tool, for that matter) should never throw a false positive. It's ok to miss some problems, but it's definitely not ok to highlight correct code as a problem. I need the confidence to know that if RubyMine is telling me something is wrong, I have to look at it -- I shouldn't ignore warnings.


Currently, RubyMine highlights way too many false positives. Most warnings in my project are in fact false positives, and I've reported numerous issues about it. Here's a few suggestions that I believe would greatly reduce the number of false positives, if not eliminate them:

If RM can't infer the type of an object, don't highlight any messages sent to this object as an error/warning.

    What RubyMine version do you use? 1.0 is supposed not to warn user in such case. Could you please provide some example?

    If RM does know the object type, but this type has method_missing defined, don't highlight any messages sent to this object as an error/warning.
    The second rule could be tightened for a few classes with known method_missing patterns, like ActiveRecord::Base.

    Do you have option File | Settings | Inspections | Ruby | Unresolved Ruby reference | Warn about implicit text matched resolve results disabled or enabled? If you turn it off you'll get less warnings.

    If RubyMine keep throwing all these false positives, the user is going to loose confidence, sooner or later. He will sooner or later loose the patience to look at all those warnings, and just ignore them. When this happens, RubyMine looses it's usefulness. Don't let this happen, please.

    Our main intention is to reduce number of false positives reported. Each report about wrong false positives helps us making RubyMIne smarter. Thanks a lot.

    Regards,
    Oleg

    Regards,
    Oleg

    0
    Avatar
    Permanently deleted user

    Thanks for your reply, Oleg. Now to answer your questions:

    Yes, I'm using 1.0 but in my original post I was mostly ranting about the general state of RubyMine inspections and thinking how I believe inspections should be dealt with in general, instead of pointing specific bugs (there's Jira for that). Sorry if I sounded otherwise. In other words, a more direct answer to your first question is no, I don't have any specific examples of RM highlighting errors for unknown types. It's good to hear that will probably not happen.

    I do have lots of examples of RM showing warnings for messages sent to objects with method_missing defined, however. From my current project:

    image = MiniMagick::Image.from_blob(attachment.data)
    image.resize(PublicController::THUMBNAIL_SIZES[:large])

    The resize call is highlighted as an unresolved reference, but MiniMagic::Image has method_missing defined:

    def method_missing(symbol, *args)
      args.push(@path) # push the path onto the end
      run_command("mogrify", "-#{symbol}", *args)
      self
    end

    In other words, there's no way for RM to know what messages will actually work. Technically speaking, this object accepts any message, and RM should never highlight anything sent to this message as an unresolved reference.

    Do you have option File | Settings | Inspections | Ruby | Unresolved Ruby reference | Warn about implicit text matched resolve results disabled or enabled? If you turn it off you'll get less warnings.

    Disabled, I have all inspections with their default settings. I'm testing how well RubyMine works for new users, after all.

    Our main intention is to reduce number of false positives reported. Each report about wrong false positives helps us making RubyMIne smarter.

    I know, and you have been doing a great job at that -- I've reported dozens of false positives, and most of them have been corrected.

    It's just that... It's hard to know for sure without access to source code, but I have this feeling that there's something fundamentally wrong with RM approach to unresolved references, there are way too many false positives. I appreciate your effort fixing the reported bugs, but maybe something needs to be turned upside down to make sure that false positives are never reported, and instead I'd be opening bugs asking for more error detection scenarios

    0
    Avatar
    Permanently deleted user

    Hi Oleg,

    I agree with you in general (resurrecting this old thread), but I'd love to see a way to 'ignore' false positives that also gives one the option (checkbox checked by default, perhaps) to report this as a false positive at the same time one is 'ignoring' it in this specific case.  In the same way that 'Alt-Enter' allows one to add typos to the dictionary, I'd like to be able to ignore an error highlight for a specific case (and easily report it at the same time)...

    For instance, here's my latest false positive in a view (RubyMine 3.0 RC2):

    <!doctype html>
    <html>
    <head>
    </head>
    <% if @foo == true %>
      <body >
    <% else %>
      <body >
    <% end %>

    blah

    </body>
    <html>
    <!-- gives warning here about body element not closed -->

    I'd like to turn off this error and report it at the same time...  I'd be happy to add a line of text describing the error, or submit the entire file, or parts of it, while turning off the error.  Perhaps that will give you better false positive reports and allow developers to easily get rid of the 'clutter' of false positives at the same time?

    Thanks for listening!

    ~ Brad

    0
    Avatar
    Permanently deleted user

    Hello Bradford,

    Thanks a lot for your example, could you please file an issue at: http://youtrack.jetbrains.net/issues/RUBY

    Regards,
    Oleg

    0

    请先登录再写评论。