UEXInspectionTransformOptions

(Difference between revisions)
(Inconsistencies and gaps)
 
Line 19: Line 19:
===Inconsistencies and gaps===
===Inconsistencies and gaps===
-
* Cannot reuse custom inspection configuration -> Project. Only the Default configuration can be copied over to the project.
+
* '''[A]''' Cannot reuse custom inspection configuration -> Project. Only the Default configuration can be copied over to the project.
-
* "new" inspection can be defined in Transform, but not in Inspect or Options. Still once a new inspection is defined, it is visible in Options, too.
+
* '''[B]''' "new" inspection can be defined in Transform, but not in Inspect or Options. Still once a new inspection is defined, it is visible in Options, too.
-
* Configuration 'Default' shared between Transform and Options, but not between Inspect and Options (possibly just defect)
+
* '''[C]''' Configuration 'Default' shared between Transform and Options, but not between Inspect and Options (possibly just defect)
-
* Transform - Manage Configuration lists passive inspections, while Transform - Select single does not
+
* '''[D]''' Transform - Manage Configuration lists passive inspections, while Transform - Select single does not
-
* Options list Findbugs as a "language"; it is not a language, but rather a vehicle for checking Java language files. The mess gets amplified if Code Sniffer or Mess Detector will be integrated with Tools | Options
+
* '''[E]''' Options list Findbugs as a "language"; it is not a language, but rather a vehicle for checking Java language files. The mess gets amplified if Code Sniffer or Mess Detector will be integrated with Tools | Options
-
* Findbugs in Options provides an option 'Run in Editor', unlike all the other hint types. If Options is to define Default configuration for file analyzers, it should also provide access to Mess Detector and Code Sniffer.
+
* '''[F]''' Findbugs in Options provides an option 'Run in Editor', unlike all the other hint types. If Options is to define Default configuration for file analyzers, it should also provide access to Mess Detector and Code Sniffer.
 +
* '''[Q]''' The Tools - Editor - Hints suggests only the editor appearance (live analyzers) are configured. With the presence of FindBugs, also file analyzer settings are provided.
===Some more controversial inconsistencies===
===Some more controversial inconsistencies===
====Different 'level' of fixed entries in Configuration selector====
====Different 'level' of fixed entries in Configuration selector====
-
Different 'level' of entries in Configuration selector: file analyzers, live analyzers, configurations which mix file and live analyzers.  
+
Different 'level' of entries in Configuration selector: file analyzers, live analyzers, configurations which mix file and live analyzers. Consider additional Analyzers will be added for individual languages: PHP, Javascript. With current implementation, the Analyzer combo would contain
-
 
+
-
Consider additional Analyzers will be added for individual languages: PHP, Javascript. With current implementation, the Analyzer combo would contain
+
* Predefined
* Predefined
** All analyzers
** All analyzers
Line 47: Line 46:
With the above list, it's not immediately obvious that:
With the above list, it's not immediately obvious that:
-
* Findbugs and NB Java hints work for Java; Code Sniffer, Mess Detector and PHP Hints work for PHP. My opinion is that the user is far more interested in language or technology to be inspected that the actual vehicle performing the inspection. The user eventually learns what each analyzer does, but selecting a low-level detail (inspection tools) should only follow selection of a higher-level information, such us the target language/technoligy.
+
* '''[G]''' Findbugs and NB Java hints work for Java; Code Sniffer, Mess Detector and PHP Hints work for PHP. My opinion is that the user is far more interested in language or technology to be inspected that the actual vehicle performing the inspection. The user eventually learns what each analyzer does, but selecting a low-level detail (inspection tools) should only follow selection of a higher-level information, such us the target language/technoligy.
-
* "All analyzers" runs everything, but respecting the configuration. User must read the items and understand the "All analyzers" is a different entity from individual Analyzers listed below
+
* '''[H]''' "All analyzers" runs everything, but respecting the configuration. User must read the items and understand the "All analyzers" is a different entity from individual Analyzers listed below
-
* there are the user-defined configurations. They are last, and even scrolled out of the chooser dropdown initially.
+
* '''[I]''' there are the user-defined configurations. They are last, and even scrolled out of the chooser dropdown initially.
-
====Cannot reuse custom inspection configuration -> Editor====
+
====Custom Configurations and Editor====
The user must mirror the necessary changes to the Default configuration. From a high-level perspective, a Configuration represents a certain ''quality goal or metric'' which should be achieved, or at least be measured for the sources. While the goal check (Inspect) checks one Configuration, routine coding work (Editor hints) then is not guided towards that desired goal (the defined Configuration) but towards a different goal described by the builtin Configuration "Default".
The user must mirror the necessary changes to the Default configuration. From a high-level perspective, a Configuration represents a certain ''quality goal or metric'' which should be achieved, or at least be measured for the sources. While the goal check (Inspect) checks one Configuration, routine coding work (Editor hints) then is not guided towards that desired goal (the defined Configuration) but towards a different goal described by the builtin Configuration "Default".
-
===UI inconsistencies===
+
This means
 +
* '''[J]''' Custom Configuration cannot be easily displayed in the Editor, although analyzer implementation support such usage
 +
* '''[K]''' While inspections (quality goals) can be switched, code assistance can not be switched accordingly.
 +
 
 +
===Cross-feature inconsistencies===
-
====Hint management dialog====
 
We have 3 features:
We have 3 features:
* Editor Hints
* Editor Hints
Line 69: Line 71:
The screenshots above all work with Hints, yet they are different as indicated by the red marks:
The screenshots above all work with Hints, yet they are different as indicated by the red marks:
-
* the Configurations are global (above project level), yet they are not visible in Options
+
* '''[L]''' the Configurations are global (above project level), yet they are not visible in Options
-
* once a custom [java] Inspection is created, it is visible in Options, yet neither Inspect or Options contain UI for add/delete custom inspections
+
* '''[M]''' once a custom [java] Inspection is created, it is visible in Options, yet neither Inspect or Options contain UI for add/delete custom inspections
-
* severity is not available sometimes
+
* '''[N]''' severity is not available sometimes
-
=== Complex UI implementation ===
+
Unrelated to the screenshots:
-
The current implementation of the management UI in java hints is reported to be fragile: in development, care must be taken that the dialog works well and looks acceptably in all the situations, with some controls hidden.
+
* '''[R]''' Per-project settings only contain NetBeans Java Hints analyzer settings; its UI suggests it should support also PHP, HTML, CSS. Note that CSS+HTML is relevant in HTML5, Web and possibly even J2SE projects.
-
There is potentially a lot of layout issues with parts of the dialog disabled conditionally depending on the context.
+
-
Additional implementations for other languages are bound for similar code complexity issues, which does not seem the right way.
+
=== Complex UI implementation ===
 +
The current implementation of the management UI in java hints is reported to be fragile: in development, '''[O]''' care must be taken that the dialog works well and looks acceptably in all the situations (currently approx 6 different contexts), hiding selectively some controls.
 +
My opinion is that such reuse brings a lot of layout and functional issues with parts of the dialog disabled conditionally depending on the context.
-
===Broken workflow===
+
'''[P]''' Additional implementations for other languages are bound for similar code complexity issues, which does not seem optimal.

Current revision as of 08:44, 26 June 2013

Contents

Motivation

The Source | Inspect and Refactor | Inspect & Transform are now rather java centric. While Source | Inspect supports 'analyzers' (and we have PHP analyzers already), it does not support hints except for java language. Adding additional hints as 'analyzers' seems to rather pollute the selector, and with further languages the 'analyzer' concept becomes even more cluttered.

Because there are notable inconsistencies, defects and omissions in UIs that manage or work with hint infrastructure, the UI could be reviewed and revisited as a whole to better accommodate additional language inspections and possibly to streamline, or fix user workflow in the IDE.

Term definitions

  • File Analyzer: analyzer which works with disk files. Possibly 3rd party library or executable
  • Live Analyzer: analyzer running on NetBeans platform, or with an agent, capable of reading editor contents
  • Passive inspection: inspection that does not provide a fix / refactoring. Typically a hint that originates from report of an external analyzer
  • Active inspection: inspection that provides a fix / refactoring (or more fixes).
  • Inspect will be used as a shortcut for Source | Inspect action and the appropriate UI
  • Options will represent the UI found at Tools | Options - Editor - Hints
  • Transform identifies the Refactor | Inspect & Transform action and the relevant UI

Identified issues

Inconsistencies and gaps

  • [A] Cannot reuse custom inspection configuration -> Project. Only the Default configuration can be copied over to the project.
  • [B] "new" inspection can be defined in Transform, but not in Inspect or Options. Still once a new inspection is defined, it is visible in Options, too.
  • [C] Configuration 'Default' shared between Transform and Options, but not between Inspect and Options (possibly just defect)
  • [D] Transform - Manage Configuration lists passive inspections, while Transform - Select single does not
  • [E] Options list Findbugs as a "language"; it is not a language, but rather a vehicle for checking Java language files. The mess gets amplified if Code Sniffer or Mess Detector will be integrated with Tools | Options
  • [F] Findbugs in Options provides an option 'Run in Editor', unlike all the other hint types. If Options is to define Default configuration for file analyzers, it should also provide access to Mess Detector and Code Sniffer.
  • [Q] The Tools - Editor - Hints suggests only the editor appearance (live analyzers) are configured. With the presence of FindBugs, also file analyzer settings are provided.

Some more controversial inconsistencies

Different 'level' of fixed entries in Configuration selector

Different 'level' of entries in Configuration selector: file analyzers, live analyzers, configurations which mix file and live analyzers. Consider additional Analyzers will be added for individual languages: PHP, Javascript. With current implementation, the Analyzer combo would contain

  • Predefined
    • All analyzers
    • JRE 8 Profile Conformance
    • Findbugs
    • NetBeans Java Hints
    • Code Sniffer
    • Mess Detector
    • NetBeans PHP Hints
    • NetBeans Javascript Hints
    • NetBeans HTML Hints
  • Custom
    • Default
    • My Config

With the above list, it's not immediately obvious that:

  • [G] Findbugs and NB Java hints work for Java; Code Sniffer, Mess Detector and PHP Hints work for PHP. My opinion is that the user is far more interested in language or technology to be inspected that the actual vehicle performing the inspection. The user eventually learns what each analyzer does, but selecting a low-level detail (inspection tools) should only follow selection of a higher-level information, such us the target language/technoligy.
  • [H] "All analyzers" runs everything, but respecting the configuration. User must read the items and understand the "All analyzers" is a different entity from individual Analyzers listed below
  • [I] there are the user-defined configurations. They are last, and even scrolled out of the chooser dropdown initially.

Custom Configurations and Editor

The user must mirror the necessary changes to the Default configuration. From a high-level perspective, a Configuration represents a certain quality goal or metric which should be achieved, or at least be measured for the sources. While the goal check (Inspect) checks one Configuration, routine coding work (Editor hints) then is not guided towards that desired goal (the defined Configuration) but towards a different goal described by the builtin Configuration "Default".

This means

  • [J] Custom Configuration cannot be easily displayed in the Editor, although analyzer implementation support such usage
  • [K] While inspections (quality goals) can be switched, code assistance can not be switched accordingly.

Cross-feature inconsistencies

We have 3 features:

  • Editor Hints
  • Inspection
  • Inspect and Transform

While the features provide different output, which correspond to the expected (supported) workflow, their configuration also varies, which reportedly confuses the users.

The screenshots above all work with Hints, yet they are different as indicated by the red marks:

  • [L] the Configurations are global (above project level), yet they are not visible in Options
  • [M] once a custom [java] Inspection is created, it is visible in Options, yet neither Inspect or Options contain UI for add/delete custom inspections
  • [N] severity is not available sometimes

Unrelated to the screenshots:

  • [R] Per-project settings only contain NetBeans Java Hints analyzer settings; its UI suggests it should support also PHP, HTML, CSS. Note that CSS+HTML is relevant in HTML5, Web and possibly even J2SE projects.

Complex UI implementation

The current implementation of the management UI in java hints is reported to be fragile: in development, [O] care must be taken that the dialog works well and looks acceptably in all the situations (currently approx 6 different contexts), hiding selectively some controls. My opinion is that such reuse brings a lot of layout and functional issues with parts of the dialog disabled conditionally depending on the context.

[P] Additional implementations for other languages are bound for similar code complexity issues, which does not seem optimal.

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo