[ 
https://issues.apache.org/jira/browse/GROOVY-8570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16474177#comment-16474177
 ] 

Paul King commented on GROOVY-8570:
-----------------------------------

I am okay with Groovy devs using bad style. I encourage them to use codenarc 
(and/or other means) to improve their style. I see the degree of badness as a 
spectrum and currently a fairly broad spectrum. I agree you have pointed out 
some things that some would regard as higher on the spectrum than some of the 
other errors.

Just for completeness, warnings are something partially supported already, e.g. 
in the anltr2 grammar there are three warnings declared, you can see one of 
them in use here but I think they are normally totally ignored:
{code}
import org.codehaus.groovy.antlr.parser.*

def s = new StringReader('for (int i : 3..5) { }')
def parser = new GroovyRecognizer(new GroovyLexer(s).plumb())
parser.warningList = []
parser.compilationUnit()
println parser.warningList[0].warning
println parser.warningList[0].solution
{code}
Which gives:
{noformat}
A colon at this point is legal Java but not recommended in Groovy.
Use the 'in' keyword.
{noformat}
We also have three warnings when processing AST transforms, e.g.:
https://github.com/apache/groovy/blob/master/src/main/java/org/codehaus/groovy/transform/ASTTransformationVisitor.java#L241
With different severity levels of warning possible as defined here:
https://github.com/apache/groovy/blob/master/src/main/java/org/codehaus/groovy/control/messages/WarningMessage.java
 

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

Reply via email to