[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-ui-dev] RE: [jdt-core-dev] Suggestion for reorganizing compiler preferences...
|
Ed,
Not all problems in the compiler are configurable. Except for the 2 ones I
suggested to remove (unreachable code, unresolved imports) most of the
problems which are detected are mandatory errors as per spec. The extra
detected problems are configurable, depending on how picky you are.
|---------+---------------------------->
| | "Ed Burnette" |
| | <Ed.Burnette@sas.|
| | com> |
| | Sent by: |
| | jdt-ui-dev-admin@|
| | eclipse.org |
| | |
| | |
| | 07/08/2003 10:00 |
| | PM |
| | Please respond to|
| | jdt-ui-dev |
| | |
|---------+---------------------------->
>----------------------------------------------------------------------------------------------------------------|
| |
| To: <jdt-ui-dev@xxxxxxxxxxx> |
| cc: <jdt-core-dev@xxxxxxxxxxx> |
| Subject: [jdt-ui-dev] 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
>
_______________________________________________
jdt-ui-dev mailing list
jdt-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-ui-dev
