UEXInspectionTransformOptions

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