Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [jdt-core-dev] Suggestion for reorganizing compiler preferences... 
Keeping these tabs organized is a great idea. (I think the Java Editor preferences needs a similar treatment.)

May I suggest having an extra preference page level for the compiler to simplify it a little and make it more usable on smaller screens? The current arrangement mixes general compiler options and problem settings in a confusing way. How about separating them like this:

+ Compiler
  |-Problems

The Compiler page would have these tabs:
   Compliance
      (current contents of JDK Compliance group)
   Code Generation
      (current contents of Classfile Generation group)
   Output
      (x Clean output folders on full build
       x Enable using exclusion patterns in source folders
       x Enable using multiple output locations for source folders
       Enter resources...
       Filtered Resources: _____
      )

The Problems page would have these tabs:
   General
   - Local variable is never read (Missing?)
   - Methods with a constructor name
   - Possible accidental boolean assignment
   - Superfluous semicolon                                     NEW
   - Unreachable code (leave since it could still be helpful in rare cases)
   - Unresolvable import statements (leave since it could still be helpful in rare cases)
   - Maximum number of problems reported per compilation unit

   Visibility
   - Access to non-accessible member of an enclosing type
   - Conflict of interface method with protected 'Object' method
   - Field declaration hides another field or variable
   - Hidden catch blocks
   - Local variable declaration hides another field or variable
     +- Include constructor or setter method parameters
   - Methods overriden but not package visible

   Efficiency
   - Assignment has no effect
   - Indirect access to static member                          NEW
   - Non-static access to static member
   - Usage of deprecated API
     +- Signal use of deprecated API inside deprecated code
   - Using a char array in string concatenation

   Unused Code
   - Unused imports
   - Unused local variables
   - Unused parameters
     +- Signal unused parameters when overriding concrete method. MISSING
     +- Signal unused parameters when implementing abstract method.  MISSING
   - Unused private types, methods or fields

   I18N
   - Usage of non-externalized strings
   - String concatenation (next 4 are from bug #38332)
   - Locale sensititive methods
   - Embedded strings
   - Embedded characters

   Build Path
   - Circular dependencies
   - Duplicated resources
   - Incompatible required binaries
   - Incomplete build path
   x Abort building on build path errors

Looking at Iproblem.java it seems like there are a lot of other problems that could be made visible but I didn't have time to go through them all.

Where possible I've suggested sorting the options in alphabetical order (at least for English). This is not a big deal but might make problems easier to find and enable/disable.


> -----Original Message-----
> From: Philippe P Mulet [mailto:philippe_mulet@xxxxxxxxxx] 
> Sent: Thursday, July 03, 2003 5:41 AM
> To: jdt-ui-dev@xxxxxxxxxxx
> Cc: jdt-core-dev@xxxxxxxxxxx
> Subject: [jdt-core-dev] Suggestion for reorganizing compiler 
> preferences...
> 
> 
> With recent additions of new compiler options, I noticed that 
> our layout is
> reaching its limit again, thus I am proposing the following:
> 
> Common Mistakes (i.e. old Style options which are currently 
> defaulting to
> WARNING)
> - Methods overriden but not package visible
> - Methods with a constructor name
> - Conflict of interface method with protected 'Object' method
> - Hidden catch blocks
> - Non-static access to static member
> - Assignment has no effect
> - Using a char array in string concatenation
> 
> Obsolete Code (i.e. old Problems options with a few moved elsewhere)
>       - Unreachable code                                    
> REMOVE since
> turning off isn't JLS compliant (historical option for VAJ 
> migration, no
> longer an issue)
>       - Unresolvable import statements                      
> REMOVE since
> turning off isn't JLS compliant (historical option for VAJ 
> migration, no
> longer an issue)
> - Unused local variables
> - Unused parameters
>   +- Signal unused parameters when overriding concrete method.
> MISSING
>   +- Signal unused parameters when implementing abstract 
> method.  MISSING
> - Unused imports
> - Unused private types, methods or fields
> - Usage of deprecated API
>   +- Signal use of deprecated API inside deprecated code
> 
> Advanced Diagnosis (i.e. old Style options which are 
> currently defaulting
> to IGNORE + max number of problems per unit)
> - Superfluous semicolon                                     NEW
> - Indirect access to static member                          NEW
> - Access to non-accessible member of an enclosing type
> - Possible accidental boolean assignment
> - Local variable declaration hides another field or variable
>   +- Include constructor or setter method parameters
> - Field declaration hides another field or variable
> - Usage of non-externalized strings
> - Maximum number of problems reported per compilation unit
> 
> Compliance and Classfiles
> - same as current
> 
> Build Path
> - same as current
> 
> 
> _______________________________________________
> jdt-core-dev mailing list
> jdt-core-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/jdt-core-dev
>

Back to the top