[
https://issues.apache.org/jira/browse/GROOVY-8570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16471773#comment-16471773
]
Paul King commented on GROOVY-8570:
-----------------------------------
I am +1 on the idea of warning support in general. But with a YAGNI hat on,
before I introduced it, I'd identify some errors first that we believe would be
definitely included and enabled by default. I'm +1 on further examination of
providing a hook to invoke codenarc as part of/in conjunction with the compiler.
I am currently -1 on the two proposed warnings being enabled by default. And if
we had the codenarc integration, then I would probably be -1 on having those
warning be part of the compiler.
For me, Groovy has always had a relaxed rather than opinionated approach to
legacy syntax within your Groovy files. You can start with Java and slowly
embrace more Groovy idioms. If someone wants to use the classic for loop then
let them even if it is totally redundant in most cases. If I want to embrace
more Groovy idioms, codenarc comes to the rescue.
I have been meaning to devote some time to finding some warnings which I
believe would be good candidates to consider now but I have been a little too
busy with other things.
> Support Warnings in Groovy Compiler
> -----------------------------------
>
> Key: GROOVY-8570
> URL: https://issues.apache.org/jira/browse/GROOVY-8570
> Project: Groovy
> Issue Type: New Feature
> Components: Compiler
> Affects Versions: 3.0.0-alpha-3
> Reporter: mgroovy
> Priority: Major
>
> * To warn Java developers using e.g. non-idiomatic Groovy constructs which
> only exist to support copy-and-paste Java-to-Groovy code compatibility, The
> Groovy compiler should support compiler warnings in addition to compiler
> errors.
> * Warnings should by default only be emitted in special circumstances such
> as the one described above, and not spam developers with an endless stream
> of, often subjectve, messages on "how to use Groovy correctly".
> * Sample warnings:
> # WARNING: Using curly braces Java style array literals (\{...}) is not
> idiomatic Groovy. To avoid confusion with Groovy closures, it is recommended
> to use the performance-identical Groovy square bracket list literal syntax
> ([...]) instead.
> # WARNING: The 'var' keyword is currently only an alias to 'def' (i.e.
> Object) in Groovy. To get reassignment type safety use an explicit type
> instead.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
