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