Inspection UI Feedback (As of build 6951)

Inspection UI Feedback (As of build 6951)

Following is a summary of enhancement requests (and a few bugs)
for the UI related to Inspections.

I was overall pleased with the improvements in Demetra release
in this area, and already as of Selena EAP 6951 there have been
two notable improvements:

  • Analyze tasks run in the background.

  • The Intention Popup List (ALT+ENTER) now groups the

Quickfixes and Intentions into separate groups separated by a
divider line.
(See http://www.jetbrains.net/confluence/display/IDEADEV/EAP6951Release+Notes)


I think if the UI related to inspections is productive and enjoyable
that will make IntelliJ's ever expanding stable of inspections more
accessible and a more valuable feature overall.

Summary of Top Requested Features
-


      • Need filter/highlighter for new inspections in the Settings -

Errors panel. When someone upgrades to 7.0 from 6.0 (or 5.0),
it is very difficult to tell which inspections are new because
there are so many. It's hard to be excited over 50 new
inspections when you can't even pick them out of the list
easily. Also need to highlight inspections with quickfixes. See
"Settings - Errors - Inspection Profile Management" for more
details.

      • Improve Inspection Tooltips in the Editor so you can access

inspection description and quickfixes/suppression actions
without having to popup the Intention Menu. See "Editor"
section below for more details.

Previous Discussion
-


Inspection UI Feedback (As of build 5646)
http://www.intellij.net/forums/thread.jspa?threadID=250972

Inspection UI Bugs & Enhancements (As of build 5561)
http://www.intellij.net/forums/thread.jspa?threadID=240249

18 comments
Comment actions Permalink

Settings - Errors - Inspection Profile Management
-



*+ Usability - Filter/highlighter for new inspections in
the Settings - Errors panel.*]

When someone upgrades to 7.0 from 6.0 (or 5.0), it is very
difficult to tell which inspections are new because there are
so many. It's hard to be excited over 50 new inspections when
you can't even pick them out of the list easily.

Right now, it is discouraging to spend hours to wade through the
entire list again, because IDEA has so many inspections now, I
end up reconsidering each inspection, because for most I can't
tell if they are new or not, or do they hae a new option or not.

  • *I would like a filter box at the top to allow the user to

choose to show only inspections added since version X*, e.g.
"Added since ". A "created-in-version" field would need
to be added to each inspection in order to support this feature.

  • *Inspections should be decorated with a 'new' icon if their

'created-in-version' matches the IDEA Project major version. *
This would help tremendously.

  • *If you wanted to get fancy, you could have an 'updated-in-version'

field for each inspection. If the 'updated-in-version' field
matches the IDEA product version (and it wasn't new that release),
the inspection tree node should be decorated with an 'updated' icon.*
This would be used in cases where the inspection added some new
options or now checks for some new cases, etc.

+ Allow the user to mark inspections as hidden. By hiding the
inspection, this will automatically turn it off in your
profiles, and also make hide it in the inspection tree. You
could have a filter to display these hidden inspections.

There have been complaints that the sheer number of inspections
is overwhelming. One possibility is to allow the user to
actually hide inspections which they never want to see. Many of
the inspections are specific to like GWT or Javascript and also
many inspections have to do with code style. I know personally
that there are more than 50% of the inspections I never want to
see and if I could remove them, it would make it easier to
manage the remainder.

+ DISCUSSION about lock inspection profile feature added in IDEA 6.0]

In IDEA 6.0, a lock icon was introduced which allowed you to
lock a profile. By default, when someone upgrades, each
unlocked profile will have any new inspections added to them
with their default settings. While Jetbrains has said this
behavior is intended so that users who never customize Error
profiles will automatically gain the benefit of new inspections,
this can be very confusing for someone who has already
customized their error profile.

The locking works fine if you thought to do it beforehand, but
I can see most won't think to do this ahead of time and will
only release the problem once all their inspections profiles
are polluted with a bunch of new inspections. Someone's
inspection profile "unused variables" will then not only check
for unused variables but also 50 new inspections after they
upgrade to 7.0.

I kind of liked Marcus Brito's idea that only the default IDE
and Project profiles should automatically inherit new
inspections. That would would avoid polluting everyone's
special purpose profiles. But if you did that, than what would
happen to this lock feature?

Maybe what we should have done in IDEA 6.0 is to automatically lock all
new profiles, since this would give a similar benefit. Currently,
you have to remember to lock the profile.

    • So, my current recommendation is that all new profiles should

be automatically locked.* This way, a user who never customizes
his error settings or only customizes the default profile will
still inherit all new inspections that default on, as Jetbrains
intends. But anyone creating new profiles will have them locked
automatically, which will reduce the pollution of special
purpose profiles.

0
Comment actions Permalink

Settings - Errors - Misc
-



+ Cosmetics - It is somewhat unusual that the lock toolbar button
displays the lock state of the currently selected error profile.
*It would be more intuitive if the profile icon was decorated with a lock
icon or just show a lock/unlocked icon next to the profile icon.*
Currently, the default profile icon is decorated by a 'D'. One possibility,
is to just add some text "(default)" to the default profile's label
which is probably clearer anyway, and then it would be easier to
decorate the profile icon with the lock icon.

- Cosmetics - The icon you are using for the IDE profile is a
generic wrench/gear, and the project profile is a document
decorated with wrench/gear in bottom-right corner.

*Couldn't you just use the mr. inspector icon? That is how it is
displayed in the status bar that shows the current editor
highlighting profile.* This would be more consistent.

You are currently using mr. inspector icon for the 'show/hide
global inspection' toolbar icon. I would change that to a globe/
earth icon to represent global, then you can use mr. inspector
for the profile icons.

- Useability - CTRL+BACKSPACE would be nice in search field box.
Currently, the search editfield box doesn't support a user's
basic editing keybindings.

This isn't just a problem for IDE Settings->Errors dialog, but
all throughout IDEA there is this problem. It would be great if
you created an enhance IDEA TextField widget which supported
user's editor keybindings. (See related IDEA-9198)

IDEA TextFields should support user's basic editing keybindings like Delete to Word Start, Select Word at Caret, etc. and CamelCase support
http://www.jetbrains.net/jira/browse/IDEA-9198

- Terminology - There is a toolbar icon to show Global
Inspections, but the problem with this is that when enabled,
the inspections which are displayed have the text "(available
for Analyze|Inspect Code)". Shouldn't this be "Global
Inspection" to be consistent, or change the Hide/Show Global
Inspection to "Hide/Show inspections only available for
Analyze|Inspect Code" Furthermore, you could show the global
icon next to each of these inspections to make it even clearer.

- Terminology - Shouldn't "Errors" be called "Inspections"?
Also "IDE Profiles" and "Project Profiles" should be "IDE
Inspection Profiles" and "Project Inspection Profiles". *I think
some people find it confusing that the word Inspection isn't
more prominent in this dialog, esp. when most of the places
that link to it use the word "Inspection".* For example,
Analyze->Inspect Code says "Inspection profiles" but when you
click "..." to edit the profiles, you see they are just named
"IDE profiles" and "Project profiles". uses terms "IDE
profiles" and "Project profiles", but

Improve usability of inspection settings dialog
http://www.jetbrains.net/jira/browse/IDEA-11223

0
Comment actions Permalink

Inspection Results Panel
-



+ *Would it be possible to show the results as you find them,
similar to when you do a search?*] Some of these inspection
take hours to run, and it would be better if I could look at
them sooner rather than later. Also, if you get tired of
waiting for it to finish, you could cancel it and still be able
to look at what it had found so far. Find in Path works like
that.

+ 'Rerun inspections' closes the result panel, while it should reuse it.]

http://www.jetbrains.net/jira/browse/IDEABKL-3244

+ *Useability: After I apply a quickfix, if it caused the line number to change, then
it causes the result item to change to INVALID, and you can no longer click
on it.*

It would be so much better if the original text was preserved and instead you
added wavy red lines or something to indicate it was INVALID. (Again, the
style could be customized in Colors&Fonts, call it "Invalid Code Pointer" or
something.
Even if it is INVALID, I should still be able to click on it and IDEA should make
a best effort to jump the the file and line number. If the line number doesn't exist,
jump to end of file. If the file doesn't exist anymore, popup an error message or
do nothing.
(See related "IDEA Find Usages and Find in Path should make best effort to jump to source for INVALID items"
http://www.jetbrains.net/jira/browse/IDEADEV-2610)

Also, I find that the "INVALID" text if often truncated (see picture), so it is very
ugly looking in addition to annoying.

+ While accepting code inspection resolution: No indication that IDEA is working.
http://www.jetbrains.net/jira/browse/IDEABKL-435

+ *Feature: For some inspections there is a need for them to have one or
more code pointers associated with them.*] For example, when it says
variable is already defined in the scope, it would be nice if there was a
way to jump to where the other variable is defined, because sometimes it
isn't obvious in a large method. Another example, is the duplicate string
literal.

Inspection Results - Add capability for inspection results to have code pointers associated with them,e.g. for "variable is already defined in the scope", etc.
http://www.jetbrains.net/jira/browse/IDEADEV-8719

Ability to go into files detected as targets for quick fix in inspection
http://www.jetbrains.net/jira/browse/IDEABKL-4203



Attachment(s):
6951_INVALID_truncated.png
0
Comment actions Permalink

Editor - Errors/Warnings
-


  • *Improve Tooltips to see the description and access quickfixes without have

to hit ALT+ENTER.*

The error tooltip style could be improved.
Content Changes:
- *Have a little '?' link on the tooltip that when hovered/clicked
would expand the tooltip to show the full inspection description.*
This avoids having to press ALT+ENTER, RIGHT_ARROW, select
"Edit inspection profile setting", ENTER in order to see the
description. The meaning of many inspections are not obvious from
the one-line warning/error message. This would really help new
and experienced users to easier access the full description.
- *Allow the user to mouse over the tooltip and select quickfix,
suppressoin, and edit inspection actions. *This avoids having
to press ALT+ENTER.
Cosmetic Changes:
- *You could add a small border with an arrow anchor pointer to
the related line/expression.*] This is pure cosmetic sugar.


Here is more detailed description from Keith Lea :

+"It doesn't make sense to click "options" to see help about what
a warning from an inspection means. My friend charlie has been
using IDEA for a while now and he was saying it would be cool
if IDEA explained why a problem was a problem. I told him about
the "Show xx options" intention and it was just what he wanted.""

"I think the code warning system needs some fixing up to look
and work more nicely. I think every error/warning should be
instead of a small tooltip, a bigger javadoc-style tooltip,
with a link to the inspection description, options, and quick
fixes. Of course the intentions should still come up with
alt+enter. This redesign would be welcome, I think - for
example, the way "Show xx options" is the only intention if the
inspection has no quick-fixes, seems crufty and confusing.
Similarly, showing options is not much of an intention, in the
traditional definition of intention that IDEA introduced. "+

Easy access to inspection descriptions
http://www.jetbrains.net/jira/browse/IDEADEV-11004

User should not have to click "Show 'xx' options" to see description of the inspection
http://www.jetbrains.net/jira/browse/IDEABKL-4327

+ *Cosmetics - The current two pixel thick line dividing
multiple on-the-fly inspection messages is a bit ugly. *I think
it would be much nicer to use a line one pixel thick, just like
the one surrounding the message.

use thin (one pixel) line when showing multiple on-the-fly inspection messages
http://www.jetbrains.net/jira/browse/IDEABKL-1783

+ ALT+ENTER context menu should use appropriate icons.

Selena EAP 6951 made a nice improvement to the Intention Menu
(ALT+ENTER) by grouping the Quickfixes and the Intentions into
separate groups separated by a divider line. (See attached
picture for an example) A further improvement would be to use
the disable/suppress icon "mr. inspector's turned around" for
the disable inspection and suppression actions, and the edit
settings icon "wrench/gear" for the Edit Inspection profile setting
action. For "Run inspection on.." maybe you could have a mr inspector
with a green arrow? Also, it would be nice if the icons for intentions
were different from quickfixes.

Improve usability of 'inspection quickfix submenu'
http://www.jetbrains.net/jira/browse/IDEA-11222

0
Comment actions Permalink

When looking at the inspections in Settings - Errors, I would like to be able to see which inspections offer quickfixes. Quickfixes are the cool part of inspections, and I think they need to be made more visible.

Here are some possibilities:

+ Show the quickfix icon next to the inspection's name in the tree.
+ Provide a filter to to show only those inspections with quickfixes.
+ In the inspection's description, you could put something like this:

This inspection has a quickfix.

If this text appears in the description, then you could possibliy search on "quickfix" to filter the tree to only the inspection's with quickfixes.

0
Comment actions Permalink

IDE Settings - Errors - Quickfix Available filter and/or Quickfix icon decoration next to inspection name and/or Quickfix note in description.

http://www.jetbrains.net/jira/browse/IDEABKL-4328

0
Comment actions Permalink

I wanted to propose a way to streamline the application of
a set of quickfixes to a file in a single click or key press.

You know how you can reformat a file according to your code
style by invoking Code->Reformat Code. In some ways you can
think of your code style as a collection of rules similar to a
set of inspections. For instance, you may have specified to
force braces for "if ()" and "for ()" statements. There is
actually an inspection "Control flow statement without braces"
that does the same thing.

I have a inspection profile I call "Normalize" which contains
some inspection with quickfixes which I like to run that helps me
read the code easier, similar to how reformatting the code in the
style you are accustomed to makes it easier to read.

For example, some of the inspections in my "Normalize" profile:

missorted modifiers
c-style array declaration
redundant field initialization
Unnecessary 'final' for local variable
Unnecessary 'final' for method parameter
Unnecessary 'this' qualifier
Unnecessary fully qualified name
Scope of variable is too broad
Enumeration can be iteration
'for' loop replaceable by 'for each'
'while' loop replaceable by 'for each'
indexOf() expression is replaceable by 'contains()'
...

Most of these quickfixes either enforce consistency (e.g.
missorted modfiiers) or reduce unnecessary code (e..g
'for' loop replaceable by 'for each')

What I do now is invoke Analyze->Inspect Code on a file, select
my "Normalize" profile and run it. Then, after I get the result,
I have to click each inspection which found something and then
click the 'Quickfix' toolbar button to apply the quickfix for
all items.

What I would like is a way to streamline this process, something
like Code->Quickfix Code which would take an inspection profile,
run it and automatically apply all quickfixes.

It should work very similar to how Code->Reformat Code works
where it gives the choice () File () Selected text () All
files in directory with the addition of a choice of profile. It
should remember the last profile you choose so most of the time
you should be able to just hit ENTER to run it.

Please comment if you have any ideas about this. I can file a
Jira request on it.

A sidenote: One big gap in the quickfixes for this kind of code
normalization is the lack of quickfixes for any of the "Naming
Conventions" inspections. Whenever I want to adapt some code
with some hideous naming convention like this_is_a_variable, I
still have manually rename each one.

0
Comment actions Permalink

Hello Alex,

I wanted to propose a way to streamline the application of a set of
quickfixes to a file in a single click or key press.


Again you describe something that I've wanted from some time, but couldn't
put into words (or didn't take the time).
It sounds a bit similar to the "Cleanup Code" feature in the new eclipse
release.

I have to think some more about the UI.
Perhaps a special 'Cleanup' inspection profile, which has a special built-in
filter, so that you can only add QuickFix-able inspections to it?

-tt


0
Comment actions Permalink

What I would like is a way to streamline this
process, something
like Code->Quickfix Code which would take an
inspection profile,
run it and automatically apply all quickfixes.


+20. That would be a true WOW-factor!

Best Regards,
Jens

P.S.: Excellent job, Alex, all those issues you mention. JetBrains should give you a free license for that effort!

0
Comment actions Permalink

What I would like is a way to streamline this
process, something
like Code->Quickfix Code which would take an
inspection profile,
run it and automatically apply all quickfixes.


Funny you should mention that. We're just putting the finishing touches on our next product, InspectorGeneral, which does a lot of what you're asking plus a whole lot more. We know that IDEA users have gotten comfortable with inspections which clean up your code when triggered. InspectorGeneral takes that one step further, letting you automatically apply over three hundred rules for code improvement, as easily as you would trigger "Reformat Code" or "Optimize Imports" today. Code improvements include control-flow rationalization, declaration and reference cleanup, tightening of access modifiers, and even batch creation of @NotNull and @Nullable annotations. InspectorGeneral even allows you to set these fixes to occur automatically on check-in, insuring your mainline code is always as clean as possible.

On a technical level, I should note that InspectorGeneral doesn't hook into the IDEA inspection system, partially for API reasons, partly for performance and partly because some of the rules applied by InspectorGeneral are problematic to express in inspection form. Instead, we've recreated the rules in a simpler form, optimized for batch rewriting.

Assuming QA gives it's blessing and marketing gets the pressers done, InspectorGeneral will be shipping one week from today. And yes, Jens, the "Wow Factor" is extremely high.

Sixth and Red River Software
"Code with Grace and Verve"

0
Comment actions Permalink

That has really wet my appetite.
However I am a little hesitant to actually use such a tool - esp. if it is brand new.
Looking at Idea's inspections there have been lots and lots of bugs fixed, many corner cases handled and support implemented for understanding descriptor files, EL, seam defined properties, etc. (But who am I telling this anyway - guess you know best.)

How confident are you that you handled these problems, e.g. will the usage of a property of a Seam component from EL in xhtml file prevent the corresponding accesor in a JavaBean from being made protected or even maybe deleted?

0
Comment actions Permalink

Trust us, we understand that particular problem well, and take it very seriously. There are multiple levels of protection to catch as many of the common reflective access patterns as possible. Much of the rule code is adapted from the (open-source, Apache licensed) inspection and intention code already in IDEA, although in many cases, we've improved on it. We use IDEAs built-in reference resolution algorithms, including any extensions from plugins, thus catching your Seam EL case neatly. Additionally, failsafes are possible via user-specifiable annotations and other configuration. Finally, we specifically chose not to implement dead-code detection and removal as automatic action, because that would have exceeded even our high comfort levels for code automation.

We're frankly hoping this product scares and excites people, just like IDEA scared and excited people when they first saw automated refactoring in action. Fortune favors the bold.

Sixth and Red River Software
"Code with Grace and a whole lotta Verve"

0
Comment actions Permalink

"Fortune favors the bold."

And the past is littered with their corpses. :)


j/k

0
Comment actions Permalink

Wow, It's not often your prayers are answered in a day! [Maybe
I should post a few more new feature requests and see if they
magically appear!] I will try this out once you release it
although I do have some reservations about it as described.

I would be most happy if this Code->Quickfix/Cleanup Code
feature worked with the existing set of inspections/quickfixes
and didn't introduce a whole other duplicate set. As I had
proposed, you should be able to just pick from the existing set
of inspections. The current library of inspections is already
overwhelming to keep track of as I mentioned in other part of
my posts.

Also, this kind of feature I would really like to be in IDEA
proper; Not a knock against SSR, but I'm one of those diehard
EAPers. If it doesn't kill me, I'll use the EAP version. But
there is much less risk of something breaking if this Code->
Quickfix/Cleanup Code feature was integrated into IDEA. I tend
to avoid plugins unless there for 3rd party software,e.g.
yourkit and jformdesigner, just because I don't want to deal
with things breaking.

In my mind, the Inspection Gadgets is the real core of this
feature, the Code->QuickFix/Cleanup Code feature is just a UI
action layered on top. But maybe what I was thinking of is a
much simplified version of what you are doing.

I really love the stuff SSR is working on, but most of it has
been on things which I think of as core to IDEA, e.g.
refactorings and inspections. It would be great from a user
point of view if Jetbrains just paid you for your efforts.
Instead of hiring 5 more Jetbrainers, Jetbrains should just pay
SSR a princely sum to develop unique 'sticky' features like
this Code->Quickfix/Cleanup Code which help keep users locked
into IDEA instead of jumping over to the other guys.

0
Comment actions Permalink

+
I would be most happy if this Code->Quickfix/Cleanup Code
feature worked with the existing set of inspections/quickfixes
and didn't introduce a whole other duplicate set. As I had
proposed, you should be able to just pick from the existing set
of inspections. The current library of inspections is already
overwhelming to keep track of as I mentioned in other part of
my posts.+

I should have been clearer. A large part of why we are doing InspectorGeneral is the current inspection set for IDEA is so darn large. Configuration of InspectorGeneral has been kept brutally minimalist. For instance, control flow rationalization is internally implementated as 100 or so rules, controlled by a slightly tricky multi-phase engine. Externally, the user of the control flow rationalizer gets precisely three checkboxes for configuration, basically indicating whether they prefer methods/loops to return/continue early on failure, and whether they hate ternary conditional operators as much as we do. Most other rules are simply defaulted to what a rational programmer would want. We don't make you click a checkbox as to whether to simplify "if(x != true) foo();" to "if(!x) foo();" or whether old-style for-loops should be turned to for-each loops if possible. They should. Period. Other rules are applied or not based on heuristic judgements as to whether the code would be clearer if the rule was applied, something that doesn't really fit into the inspection format. Frankly even those three checkboxes seem excessive to us, but those were only control-flow style choices we could see reasonable disagreement with.

If most users had to set up inspection profiles to get this control-flow rationalization behaviour, they wouldn't. InspectorGeneral users will most likely hit Ctrl-Alt-Q, and never worry about configuration. This represents a lot of judgement calls on our part, but we believe the usability gains are well worth it.

+
I really love the stuff SSR is working on, but most of it has
been on things which I think of as core to IDEA, e.g.
refactorings and inspections.+

We do this as much from love as for profit. Code analysis and rewriting is what we enjoy doing most.

+
It would be great from a user
point of view if Jetbrains just paid you for your efforts.
Instead of hiring 5 more Jetbrainers, Jetbrains should just pay
SSR a princely sum to develop unique 'sticky' features like
this Code->Quickfix/Cleanup Code which help keep users locked
into IDEA instead of jumping over to the other guys. +

6&RR products have been rolled into the core distribution of IDEA in the past (Inspection-JS), and we are certainly open to such deals in the future. If JetBrains feels that Refactor-J or LockSmith or InspectorGeneral would be a valuable addition to their core refactoring/inspection suite, we're totally in favor of that whole "princely sum" idea.

Sixth and Red River Software
"Code with Grace and Verve"

0
Comment actions Permalink

This "Control Flow Rationalization" sounds really neat esp. the part about
"prefer methods/loops to return/continue early on failure" -- it sounds like you are taking code normalization a step farther than what is possible with the limited quickfixes in IDEA presently.

But I'm wondering why it couldn't just be included as another inspection? Lots of inspections have some configuration UI, so wouldn't "Control Flow Rationalization" fit there too?

I guess since the "ControlFlow Rationalization" does 100 different things, it is not possible for it to give you inspection results itemizing each thing it will fix before it does it?

After you explain this further, it doesn't seem that this "Control Flow Rationalization" does what I was specifically asking for, i.e. allowing me to automate the running of quickfixes in the existing inspections. I mean this Inspector General "Control Flow Rationalization" is only simplying 100 existing inspections not all of them. Does it supplant all of the java inspection quickfixes, e.g. "missorted modifiers"? And I assume it does not encompass rewriting non-Java code like javascript, XML, etc.

The ideal presentation IMO would be if "Control Flow Rationalization" was an inspection that could show you an itemized list of the changes it was going to do, similar to how the "Scope Too Broad" inspection works. And then, I could use Code->Cleanup Code command (if it existed) to run the "Control Flow Rationalization" plus any other cleanup quickfixes I wanted.

The one reservation I have with "Control Flow Rationalization" is that if it does too many things and has no preview or before/after diff, I would be reluctant to run it on large pieces of code.

The existing "Normalize" profile I use I am very confident in the inspection quickfixes because I know exactly what each one does.

0
Comment actions Permalink

I have filed a Jira request to track this feature request. Please vote for it if you are interested. Thanks.

http://www.jetbrains.net/jira/browse/IDEA-12825

I also commented that a simple UI change that would make it easier to use a "Cleanup" or "Normalize" profile is to allow quickfix to be invoked on the toplevel folder in the Inspection Results window, e.g. usually a module name.

Currently, I have to expand the inspection results tree and click on each inspection name and invoke quickfix.

By allowing quickfix on the containing folders to recursively apply quickfix, this would limit the number of clicks, so my current procedure would be reduced to:

Analyze->Inspect Code, select "Normalize" profile, Run

Click on toplevel folder, e.g. module name.
Click quickfix toolbar button to apply all quickfixes.


I still would rather have a Code->Cleanup Code action because then it can remember a different profile than the one I use for Analyze->Inspect Code. For Cleanup Code I use a special "Normalize" profile while for regular use I have another profile named "Recommended".

0
Comment actions Permalink

+
But I'm wondering why it couldn't just be included as another inspection? Lots of inspections have some configuration UI, so wouldn't "Control Flow Rationalization" fit there too?+

Here's an example of how "Control Flow Rationalization" goes beyond inspections. For any expressions foo and bar,

if(!(foo && bar))
{
}

can be replaced by
if(!(foo) || !(bar))
{
}

Now it would be trivial to create an inspection that told you about such negated ands and a quickfix to apply DeMorgan's law. The problem is that it, while such an inspection would simplify some code, it would actually complicate other code. It depends on just what foo and bar are, and on the context of the if statement, as to whether applying DeMorgan's law is a net win in terms of clarity. Because of this, we don't have an inspection for negated ands. If it existed, there would be so many false positives that it would be immediately turned off, or so many configuration switches and documentation caveats that no one would understand it. Instead we have a pair or DeMorgan's law intentions, which gives the developer the power to simplify when he thinks about it, but doesn't force his hand. That was the state of the art in 2003, and it was pretty good, but we can do better.

It turns out there are surprisingly many rules like that. There are many ways to represent equivalent control flows in Java. In addition to applying control flow rewrites that always make sense, "Rationalize Control Flow" tries to find out when rules would should only be applied in some occasions make sense. To do so, it applies a bunch of heuristics (lower average nesting levels, reduce negations) respecting a bunch of constraints (don't make expressions too long, don't combine && and ||), to optimize for clarity. Moreover, it does so greedily, so that the result of applying one rule may make another rule possible, something else inspections can't do without repeated user interaction. Until Wednesday, you'll have to take my word on the quality of the results.

Sixth and Red River Software
"Code with Grace and Verve"

0

Please sign in to leave a comment.