Error Highlighting / Error Fixing - poll

First, the error highlighting options are great. There must be about 100 or
so categories of things you can set to show as errors or warnings (I prefer
warnings for most things).

Here's the problem:

1. Setting them. You have to change each setting individually. There is
no way to click on Class Metrics or Abstraction Issues, for example, and
have all the child entries set. (Maybe, you'll concede this point but then
suggest it's a one time setup process that wont interfere with your work or
cause you much pain after you make your selections....this is not the case)
.


2. Changing them. (Somewhat a duplicate of the item above, but notice the
use case). Where this is relevant is in the case that presented itself a
few days ago:


I inherited some functionality that I had to make changes to. One class in
particular was killing me. It was about 4400 lines long. And (brace
yourself)....the right scroll bar area where error indicators are shown was
SOLID yellow (I use "set to warning" for most stuff).

This leads to next problem: because the class was so long and/or had so
many "problems" as determined by IDEA, it was killing the CPU. I was at 99%
CPU usage nearly all the time. Each keystoke took seconds to register. I
cant code like this. I need to turn off some of the error analysis and
reporting.

This leads to the next problem: (see point 1 above). You cant changes
these settings quickly. You cant set toggle a category off (or set to "do
not report"). And I sure as hell am not going to set each one individually
for one problematic class...only to have to reset the all individually when
I resume my normal work. And even if I toggled them off....

This (would) lead to the next problem: it wouldn't remember my settings.
Even I don't remember my settings. A quick look now shows that I have "Cast
to a concrete class" as Do Not Show and "Cast references one of its
subclasses" (yes, IDEA has a typo...it should read: "Cast references to
one of its subclasses"), set to As Warnings. There are many other places
where I set error reporting in a custom manner. Toggling wont be enough.
IDEA needs to remember my settings and allow me to come back to them (ie. a
temporary change). It would also need to let me change categories en masse.



So how did I solve my problem? With good old fashioned brute force...I
copied and pasted bits and chunks of the class, method by method, into IDEA.
I then "fixed" the problems reported, got rid of the Yellow lines, and
copied and pasted some more. Saddam is treated better than this.


In addition to the problems noted above and solution proposed, something
just occured to me...why did I have to fix these problems? Why couldn't
IDEA fix my problems for me? (If this is already available, I will cry. I
spent hours on this effort.) IDEA fixes my problems on a one-by-one basis.
It will flip my equalsIgnoreCase problems. But I hate clicking on each line
individually waiting for the light bulb to come up prompting me on how to
fix it. That works great for my code...I dont have too many Yellows in my
code. When I inherit code, I'd like to fix all problems of a similar nature
at one time (ie. add "final" to the variable declarations where appropriate,
for example). In other words, act like Reformat Code....just fix it. All
of it.


Am I off base? Are these good features to ask for?

(To recap)

-setting error highlighting in categories (as well as individually which
is the current method)
-remembering error highlighting settings (to be able to come back to if
the need arises to change them temporarily)
-option of fixing of problems reported in error analysis, en masse, by
category (fix all my equalsIgnoreCase problems, not just the line in
question, if I set that to Warning or Error)



Thanks...

Michael.



10 comments

IDEA would have done this for you if you went to Analyze->Inspect Code...,
ran inspections for all of the problems you wanted to look for, and then
selected all of the "can be final" results in the results pane, right-clicked,
and clicked "Fix selected problems."

The Inspect Code dialog also has an idea of "profiles" so you can quickly
switch between sets of inspections. I think the editor inspections dialog
would benefit from something like this.

I think IDEA's error highlighting settings window should have a little text
box that explains that editor inspections are also available as Code Inspection
inspections, so you would have immediately seen how to do it.

-Keith

First, the error highlighting options are great. There must be about
100 or so categories of things you can set to show as errors or
warnings (I prefer warnings for most things).

Here's the problem:

1. Setting them. You have to change each setting individually.
There is no way to click on Class Metrics or Abstraction Issues, for
example, and have all the child entries set. (Maybe, you'll concede
this point but then suggest it's a one time setup process that wont
interfere with your work or cause you much pain after you make your
selections....this is not the case) ..

2. Changing them. (Somewhat a duplicate of the item above, but
notice the use case). Where this is relevant is in the case that
presented itself a few days ago:

I inherited some functionality that I had to make changes to. One
class in particular was killing me. It was about 4400 lines long.
And (brace yourself)....the right scroll bar area where error
indicators are shown was SOLID yellow (I use "set to warning" for most
stuff).

This leads to next problem: because the class was so long and/or had
so many "problems" as determined by IDEA, it was killing the CPU. I
was at 99% CPU usage nearly all the time. Each keystoke took seconds
to register. I cant code like this. I need to turn off some of the
error analysis and reporting.

This leads to the next problem: (see point 1 above). You cant
changes these settings quickly. You cant set toggle a category off
(or set to "do not report"). And I sure as hell am not going to set
each one individually for one problematic class...only to have to
reset the all individually when I resume my normal work. And even if
I toggled them off....

This (would) lead to the next problem: it wouldn't remember my
settings. Even I don't remember my settings. A quick look now shows
that I have "Cast to a concrete class" as Do Not Show and "Cast
references one of its subclasses" (yes, IDEA has a typo...it should
read: "Cast references to one of its subclasses"), set to As
Warnings. There are many other places where I set error reporting in
a custom manner. Toggling wont be enough. IDEA needs to remember my
settings and allow me to come back to them (ie. a temporary change).
It would also need to let me change categories en masse.

So how did I solve my problem? With good old fashioned brute
force...I copied and pasted bits and chunks of the class, method by
method, into IDEA. I then "fixed" the problems reported, got rid of
the Yellow lines, and copied and pasted some more. Saddam is treated
better than this.

In addition to the problems noted above and solution proposed,
something just occured to me...why did I have to fix these problems?
Why couldn't IDEA fix my problems for me? (If this is already
available, I will cry. I spent hours on this effort.) IDEA fixes my
problems on a one-by-one basis. It will flip my equalsIgnoreCase
problems. But I hate clicking on each line individually waiting for
the light bulb to come up prompting me on how to fix it. That works
great for my code...I dont have too many Yellows in my code. When I
inherit code, I'd like to fix all problems of a similar nature at one
time (ie. add "final" to the variable declarations where appropriate,
for example). In other words, act like Reformat Code....just fix it.
All of it.

Am I off base? Are these good features to ask for?

(To recap)

-setting error highlighting in categories (as well as individually
which
is the current method)
-remembering error highlighting settings (to be able to come back
to if
the need arises to change them temporarily)
-option of fixing of problems reported in error analysis, en
masse, by
category (fix all my equalsIgnoreCase problems, not just the line in
question, if I set that to Warning or Error)

Thanks...

Michael.



0

I just tried the Inspect Code (again). I forgot about that. It's been a
while since I used it. Damn, that's one hot piece of functionality. It's
got toggling of settings by category too.

Thanks a bunch Keith.


"Keith Lea" <keith@cs.oswego.edu> wrote in message
news:95106632376929385415504@news.jetbrains.com...

IDEA would have done this for you if you went to Analyze->Inspect Code...,
ran inspections for all of the problems you wanted to look for, and then
selected all of the "can be final" results in the results pane,

right-clicked,

and clicked "Fix selected problems."

>

The Inspect Code dialog also has an idea of "profiles" so you can quickly
switch between sets of inspections. I think the editor inspections dialog
would benefit from something like this.

>

I think IDEA's error highlighting settings window should have a little

text

box that explains that editor inspections are also available as Code

Inspection

inspections, so you would have immediately seen how to do it.

>

-Keith

>

First, the error highlighting options are great. There must be about
100 or so categories of things you can set to show as errors or
warnings (I prefer warnings for most things).

>

Here's the problem:

>

1. Setting them. You have to change each setting individually.
There is no way to click on Class Metrics or Abstraction Issues, for
example, and have all the child entries set. (Maybe, you'll concede
this point but then suggest it's a one time setup process that wont
interfere with your work or cause you much pain after you make your
selections....this is not the case) ..

>

2. Changing them. (Somewhat a duplicate of the item above, but
notice the use case). Where this is relevant is in the case that
presented itself a few days ago:

>

I inherited some functionality that I had to make changes to. One
class in particular was killing me. It was about 4400 lines long.
And (brace yourself)....the right scroll bar area where error
indicators are shown was SOLID yellow (I use "set to warning" for most
stuff).

>

This leads to next problem: because the class was so long and/or had
so many "problems" as determined by IDEA, it was killing the CPU. I
was at 99% CPU usage nearly all the time. Each keystoke took seconds
to register. I cant code like this. I need to turn off some of the
error analysis and reporting.

>

This leads to the next problem: (see point 1 above). You cant
changes these settings quickly. You cant set toggle a category off
(or set to "do not report"). And I sure as hell am not going to set
each one individually for one problematic class...only to have to
reset the all individually when I resume my normal work. And even if
I toggled them off....

>

This (would) lead to the next problem: it wouldn't remember my
settings. Even I don't remember my settings. A quick look now shows
that I have "Cast to a concrete class" as Do Not Show and "Cast
references one of its subclasses" (yes, IDEA has a typo...it should
read: "Cast references to one of its subclasses"), set to As
Warnings. There are many other places where I set error reporting in
a custom manner. Toggling wont be enough. IDEA needs to remember my
settings and allow me to come back to them (ie. a temporary change).
It would also need to let me change categories en masse.

>

So how did I solve my problem? With good old fashioned brute
force...I copied and pasted bits and chunks of the class, method by
method, into IDEA. I then "fixed" the problems reported, got rid of
the Yellow lines, and copied and pasted some more. Saddam is treated
better than this.

>

In addition to the problems noted above and solution proposed,
something just occured to me...why did I have to fix these problems?
Why couldn't IDEA fix my problems for me? (If this is already
available, I will cry. I spent hours on this effort.) IDEA fixes my
problems on a one-by-one basis. It will flip my equalsIgnoreCase
problems. But I hate clicking on each line individually waiting for
the light bulb to come up prompting me on how to fix it. That works
great for my code...I dont have too many Yellows in my code. When I
inherit code, I'd like to fix all problems of a similar nature at one
time (ie. add "final" to the variable declarations where appropriate,
for example). In other words, act like Reformat Code....just fix it.
All of it.

>

Am I off base? Are these good features to ask for?

>

(To recap)

>

-setting error highlighting in categories (as well as individually
which
is the current method)
-remembering error highlighting settings (to be able to come back
to if
the need arises to change them temporarily)
-option of fixing of problems reported in error analysis, en
masse, by
category (fix all my equalsIgnoreCase problems, not just the line in
question, if I set that to Warning or Error)

>

Thanks...

>

Michael.

>

>
>


0

I'd love to have something in the status bar that lets me 'disable all warnings' for the current editor, in the same vein as the 'import popups' option currently available. Although I suppose that the next step would be an option to disable all auto suggestions, and before you know it the status bar will become too cluttered to be useful!

0

Michael Morett wrote:

-remembering error highlighting settings (to be able to come back to if
the need arises to change them temporarily)


Saveable profiles are planned for Irida
(http://www.intellij.net/tracker/idea/viewSCR?publicId=15113).

Once this is implemented I hope we will be able to switch between
profiles using the standard "quick switch scheme" feature.

0


I am really looking forward to this feature in Irida.
Hopefully they do more than just make the Error Settings saveable (15113). As I suggested in 26060 and others have suggested, the error/warning settings profiles and the inspection tool profiles should be merged into one.


http://www.intellij.net/tracker/idea/viewSCR?publicId=15113
http://www.intellij.net/tracker/idea/viewSCR?publicId=26060
http://www.intellij.net/tracker/idea/viewSCR?publicId=30857

0

I think the underlying problem is that the inspections take too much CPU,
and don't give up CPU to the AWT event thread, isn't it? Maybe that should
be fixed instead.

-Keith

I'd love to have something in the status bar that lets me 'disable all
warnings' for the current editor, in the same vein as the 'import
popups' option currently available. Although I suppose that the next
step would be an option to disable all auto suggestions, and before
you know it the status bar will become too cluttered to be useful!



0


What few profilings I've been able to do indicate that the problem isn't calculating the warnings (which are basically constant-time tree-walks), it's allocating the error objects and rendering all of the yellow lines and highlights. If you've got clean code, it doesn't matter how many inspections you've got on. Besides, you were thinking about buying a faster processor anyway.


--Dave "six days as sole wrangler of a three-year-old, a bottle of cabernat-shiraz for dinner, and I still polished off the JDBC resource-closing inspection" Griffith

0

I doubt they will be merged, as there are off-line inspections which aren't doable online (notably dead code). However, I'd be surprised if error-checking profiles don't have quick-selects and aren't sharable. That's 90% of the battle right there.

--Dave Griffith

0


For me, most of the pain is keeping the Inspect Code inspections in sync with my Error Hilighting preferences..

Typically, I would spend alot of time playing with the Inspect Code tool to find out the inspections I like to run. But then, I had no way of moving these over to the Error hilighting preferences. I had to manually go through the error hilighting settings.

I understand that some inspections are only available in "Inspect Code" or vice versa, and also you might not always want to have all the inspections turned on due to cpu usage or visibility issues..

Ideally I would want the following:
1) One place to create an inspection profile.
Inspection that have restrictions like "Only for Inpsect Code" could just be marked as such. The benefit of a having a merged profile far outweighs this added complication.
2) Allow you to duplicate a current profile with a new name. This would be useful after you spent a few hours gettting the Inspect Code profile to your liking and you want to use that as your new starting point for Error/Warning hilighting.
3) The Error Hilighting panel and the Inspect Code window should share these inspection profiles, but each could have their own setting on which profile is in use. This would allow a user to have a less rigorous/more cpu friendly version for Error Hilighting.
4) As other people mentioned a way to quickswitch between error/warnings profiles.
5) An extension of 4) is to allow you to have different profiles for different codebases. For my own code, I want to use my more rigorous profile but if I'm jumping into somebody else's code or some 3rd party source code, I would want something less rigorous.

Also, I don't see why the "Inspect Code" couldn't use the Error/Warning decoration the Error Hilighting settings have. On the Inspection Results window you could have a filter to show Errors | Warnings | Both.

Also, a handy feature would be the ability to click on the error gutter and click "Show Errors/Warnings in Inspection Results window". Maybe if you click on that red/yellow square at the top. This would be especially good if this can be done without having to run an Inspect Code on this file behind the scenese. See attached picture.

-Alex



Attachment(s):
intellij_error_gutter.jpg
0

+100

Yes, yes, yes. Now that I'm using Inspect Code more often, I'm seeing the
same problems in usage. Each feature (error highlightings, inspect code) is
useful, but they belong together.

Case in point:

I had a line of code that was showing up (as a warning) telling me a
condition was always true. I thought it would be a good check to add to my
inspect code settings (I only have 3 or 4 things checked there) so I went to
add it. For the life of me, I couldn't find it. At least not for a while.
I couldn't "search" the inspect code entries so I had to look for it one
line at a time....but I was looking for the wrong thing. I should have been
looking for something called "constant condition always true" (or something
similar).


I dont know if you mentioned it below or maybe I misinterpreted, but I would
love an entry in the little popup window that comes up when you click the
light bulb (dont know what that's called...work with me, it's 12:30 am) that
says "add to inspect code settings". Voila. Done. Clicking on that new
menu item automatically checks the box for me wherever it is in that (huge)
list of inspections.

But for now, I'm just satisifed with Inspect Code. I am just kicking myself
in the ass for adding "final" all over the place on variable declarations
and method parameters. I am proud to report that the solid yellow bars on
the right side for that monstrosity of a class have been reduced to maybe 20
yellow bars or so. I damn near had an orgasm when Inspect Code fixed 189
"lack of final" problems in 2 seconds.

Then, I stumbled on Introduce Variable. Oh my god....I really need to
stop coding the old fashioned way.




"Alex" <no_mail@jetbrains.com> wrote in message
news:11062149.1102216426366.JavaMail.itn@is.intellij.net...
>

For me, most of the pain is keeping the Inspect Code inspections in sync

with my Error Hilighting preferences..
>

Typically, I would spend alot of time playing with the Inspect Code tool

to find out the inspections I like to run. But then, I had no way of moving
these over to the Error hilighting preferences. I had to manually go through
the error hilighting settings.
>

I understand that some inspections are only available in "Inspect Code"

or vice versa, and also you might not always want to have all the
inspections turned on due to cpu usage or visibility issues..
>

Ideally I would want the following:
1) One place to create an inspection profile.
Inspection that have restrictions like "Only for Inpsect Code" could just

be marked as such. The benefit of a having a merged profile far outweighs
this added complication.

2) Allow you to duplicate a current profile with a new name. This would be

useful after you spent a few hours gettting the Inspect Code profile to your
liking and you want to use that as your new starting point for Error/Warning
hilighting.

3) The Error Hilighting panel and the Inspect Code window should share

these inspection profiles, but each could have their own setting on which
profile is in use. This would allow a user to have a less rigorous/more cpu
friendly version for Error Hilighting.

4) As other people mentioned a way to quickswitch between error/warnings

profiles.

5) An extension of 4) is to allow you to have different profiles for

different codebases. For my own code, I want to use my more rigorous
profile but if I'm jumping into somebody else's code or some 3rd party
source code, I would want something less rigorous.
>

Also, I don't see why the "Inspect Code" couldn't use the Error/Warning

decoration the Error Hilighting settings have. On the Inspection Results
window you could have a filter to show Errors | Warnings | Both.
>

Also, a handy feature would be the ability to click on the error gutter

and click "Show Errors/Warnings in Inspection Results window". Maybe if you
click on that red/yellow square at the top. This would be especially good if
this can be done without having to run an Inspect Code on this file behind
the scenese. See attached picture.
>

-Alex

>


0

Please sign in to leave a comment.