Revision as of 07:26, 26 June 2013 by Sdedic (Talk | contribs)



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

  • Cannot reuse custom inspection configuration -> Project. Only the Default configuration can be copied over to the project.
  • "new" inspection can be defined in Inspect & Transform, but not in Source | Inspect or Tools | Options
  • Source | Inspect and Inspect & Transform works on global configuration items, which are not visible in Tools | Options
  • 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

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:

  • 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
  • there are the user-defined configurations. They are last, and even scrolled out of the chooser dropdown initially.

Cannot reuse custom inspection configuration -> 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".

UI inconsistencies

Hint management dialog

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:

  • 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
  • severity is not available sometimes

Complex UI implementation

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. 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.

Broken workflow

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