Error Hilightings settings work great in 3200!

Comments:
- The new ErrorHighlighting Profiles are awesome! All the
major problems have been fixed.
- Now possible to easily run Analyze->Inspect on a file
with the exact same settings as your Error Hilighting
profile. This is great when there are many of the same
problem like "missorted modifiers", becuase the
Inspection Results window lets you apply quick fix en
masse.

- The 'Edit options of "xxxx"' Intention is very nice!!

Bugs:
- The 'Edit options of "xxxx"' Intention pops up the
dialog and highlights the option name, but many times it
is not visible. I usally have to scroll up a few lines
to see it.


Other ideas for improvement:

- Inspection Results Window.
Clicking on Inspection name should display the
full description in the pane on the RHS. Currently the pane is
blank when you click the inspection name.

- At the top of the Editor Pane gutter, there is that
little red/yellow/normal colored square showing the
highest severity error in the file. If you mouse over
the square at the top of the gutter, it says something
like " Analsys completed. 50 warnings found." If you
double click that square, I think it should
automatically run inspect file with the ErrorHilighting
settings profile.

Then, when I come upon a file with a bunch of warnings, I
can double-click the square and immediately see the
inspection results window where I can apply fixes en
masse.


- The "Edit Options" choice with ALT+ENTER in the
Editor pane is very useful. I would like this option
in the Inspection Results window also.

- I would like a hilighting level below warning called
notice. The notice hilighting wouldn't show in the
gutter, but if you were looking at the code, the
expressions tagged by the inspection would be hilighted.
This is useful for certain constructs/code where you
would like it flagged because it might be non-standard,
but you don't want to flag it as an error/warning because
it could be fine.

There are a bunch of inspections which I have had to turn
off because there are too many exceptions where it is ok,
but if I could still hilight them in the Editor Pane
without gumming up the gutter, I would still enable them.

- As mentioned in another thread, I would like to assign different ErrorHilightingProfiles for different packages / workspace paths.

Specific Inspections:

- I would like quickfixes for naming convention.
(Not sure if that is possible?)
You could compare the incorrect name to the pattern and
change the minimum number of chars to fix it?
Only apply the quickfix if it only required (1)
changing case of characters (2) adding fixed text from
the pattern.

For example, with pattern m[A-Z][A-Za-z] for field, if
I have incorrect field name "id", quickfix could change
it to " mId". But if I have a field "id23422" or
"id_something", then it shouldn't apply the fix.

- Parameter name differs from parameter in overidden
method.
-- I like this inspection to help keep my code
consistent,
but it also reports when I override methods from the
JDK and other libraries. I would like option to only
check my project's classes..

Misc:
-- The default equals and hashCode() implementaiton from
Code->Generate, is flagged by Inspect as having
problems. The 'conditional expression'. It would be
nice if IDEA's generated code passes all inspections
(except in cases where two inspections contradict one
another).

13 comments
Comment actions Permalink

Alex wrote:

If you
double click that square, I think it should
automatically run inspect file with the ErrorHilighting
settings profile.


+1

- I would like a hilighting level below warning called
notice.


+1

-- The default equals and hashCode() implementaiton from
Code->Generate, is flagged by Inspect as having
problems. The 'conditional expression'. It would be
nice if IDEA's generated code passes all inspections
(except in cases where two inspections contradict one
another).


I think this is just a matter of code style. If there's no inspection
contradicting this one, it is probably just because it is easier to
detect conditional expressions being used than detecting places where
they could be used but aren't.

0
Comment actions Permalink

>I would like quickfixes for naming convention. (Not sure if that is possible?)

Naming convention inspections already have quick-fixes, but only from the editor panel. The quickfix simply triggers the "Rename" inspection, which isn't appropriate from the inspection panel, as triggering on a large selection of things to be renamed would result in an annoying flurry of rename dialog boxes popping up.

You could compare the incorrect name to the pattern and change the minimum number of chars to fix it?

Only apply the quickfix if it only required (1)
changing case of characters (2) adding fixed text from
the pattern.

I like the idea (particularly with the restrictions), and will put it in my todo list. The mechanics are trivial, it's just finding the minimal fix string that will be tricky. If anyone feels like donating code for that to the cause I'd be happy to include it.

--Dave Griffith

0
Comment actions Permalink

>Parameter name differs from parameter in overidden
method.
-- I like this inspection to help keep my code
consistent,
but it also reports when I override methods from the
JDK and other libraries. I would like option to only
check my project's classes.

Reasonable. I'll put it on my list

0
Comment actions Permalink

>-- The default equals and hashCode() implementaiton from
Code->Generate, is flagged by Inspect as having
problems. The 'conditional expression'. It would be
nice if IDEA's generated code passes all inspections
(except in cases where two inspections contradict one
another).

This is definitely a stylistic issue. I don't expect the rest of the world to share my deep and abiding distaste for the ternary conditional operator.

--Dave Griffith

0
Comment actions Permalink

>If there's no inspection
>contradicting this one, it is probably just because it is >easier to detect conditional expressions being used than >detecting places where they could be used but aren't.

Such an inspection would actually be pretty doable, but I will not be coding it, as I consider use of a conditional operator to be "worst practice". I don't expect the rest of the world to agree with me, but that's because they are WRONG, WRONG, WRONG.

--Dave Griffith

0
Comment actions Permalink

Dave

I consider use of a conditional operator to be "worst practice"




I must - softly - disagree with you here.
Used wisely, and properly formatted, conditional operators can make your
code clearer.

For example, I use this kind of writing all the time:

return (secondChoice != null)
? secondChoice
: thirdChoice ;


As I'm used to reading this kind of coding, I find it communicates
better than:

if (null != secondChoice)
return secondChoice ;
else
return thirdChoice;

or
if (null != secondChoice)
return secondChoice ;
return thirdChoice;

Alain





0
Comment actions Permalink


Alain Ravet wrote:

Dave

>> I consider use of a conditional operator to be "worst practice"



I must - softly - disagree with you here.
Used wisely, and properly formatted, conditional operators can make your
code clearer.


When used responsibly that is probably right, but I see things like this
all day:

frame.setTitle(baseTitle + (currentFile==null?"":" - " +
currentFile.getPath()+(changed?" *":"")))

And I can't count the number of times I have seen nested conditional
expressions which test the same thing twice or are nested 3 or 4 levels
deep. Refactoring that can be a pain. Strangly regular if-statements
seem to be abused much less often, so I'd rather not see conditional
expressions at all.

Bas

0
Comment actions Permalink

Bas

I see things like this all day:
frame.setTitle(baseTitle + (currentFile==null?"":" - " +
currentFile.getPath()+(changed?" *":"")))

>

What would help is a formatting inspection to track this kind of eye
sore, like:
"conditional operators must span 3 lines"



Alain

0
Comment actions Permalink

Alain Ravet wrote:

What would help is a formatting inspection to track this kind of eye
sore, like:
"conditional operators must span 3 lines"


You don't need an inspection for that, you can just set up your code
formatting options appropriately and reformat away. But I'm sure you know
that... :)

What would be good is an inspection for conditional operators that have
branches which aren't "simple", where simple is defined as:
- containing only a single literal, variable reference or method call; and
- not containing any string concatenation, arithmetic, etc.
- not containing any nested conditional operators.
It should apply the same sort of criteria to the test part as well, but
allow "simple" expressions too - containing no more than one operator, for
example.

What do you think?

Vil.

0
Comment actions Permalink

Vilya


1/

You don't need an inspection for that, you can just set up your code
formatting options appropriately and reformat away.



I use auto-formatting sparsely, because it tends to mess up my carefully
and beautifully aligned code.


2/

What would be good is an inspection for conditional operators that
have branches which aren't "simple",


That would be useful => you could spot the unclear cond-ops, and just
fix (reformat or refactor) those.

where simple is defined as:
- containing only a single literal, variable reference or method call;
and


OK

- not containing any string concatenation, arithmetic, etc.



Not OK:

? "header" + "center" + "footer"
? (10 * 3600) + (12 * 60) + 1

's intention is clearer than
? "headercenterfooter" ;
? 4321 ;


- not containing any nested conditional operators.


OK

It should apply the same sort of criteria to the test part as well,
but allow "simple" expressions too - containing no more than one
operator, for example.

>
OK


Alain

0
Comment actions Permalink

Alain Ravet wrote:
> I use auto-formatting sparsely, because it tends to mess up my carefully
> and beautifully aligned code.

Fair enough. I do like the idea of having a slightly more general
inspection, for code which doesn't match your formatting style. That could
be really handy for code reviews, for example.

>> - not containing any string concatenation, arithmetic, etc.
>
> Not OK:
>
> ? "header" + "center" + "footer"
> ? (10 * 3600) + (12 * 60) + 1
>
> 's intention is clearer than
> ? "headercenterfooter" ;
> ? 4321 ;

That's where our opinions differ, then. I think it's things like your first
example which can make the conditional operator unclear. FWIW, the way I'd
write your example would be to introduce variables for the expression in the
branch:

String str = "header" + "center" + "footer";
? str
and
int value = (10 * 3600) + (12 * 60) + 1;
? value

Anyway, there's obviously a couple of different usage patterns there so the
magic word is "configurability". :)

Vil.
--
Vilya Harvey
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/

0
Comment actions Permalink

What would be good is an inspection for conditional operators that
have branches which aren't "simple", ...
- not containing any nested conditional operators.


+1

0
Comment actions Permalink


There already is an inspection for nested conditional expressions.

--Dave Griffith

0

Please sign in to leave a comment.