I was looking at using groovy.transform.TypeChecked, but get this when trying to import: Importing [groovy.transform.TypeChecked] is not allowed
This leads me to believe that although I can put "@groovy.transform.TypeChecked" before a method, I probably shouldn't and it is the intended design that TypeChecked SHOULDN'T be used on HE?
So far, it does work as expected: [Static type checking] - Cannot return value of type java.lang.String on method returning type int
There are some important "snags" however, some variables like, eg. "state" and "location", are caught as undeclared. This is due to these variables not existing at compile time and probably is why TypeChecked can't be imported, but it would be nice to use TypeChecked...
Any thoughts? Maybe I should tag some HE staff, but for now, let's see what the collective knowledge says
I have found you can get similar analysis using IntelliJ (there is a free edition)
However larger programs can really cause IntelliJ to go 'away for a while'
It is important to remember groovy scripts end up using the types Integer, Boolean, Double (ie objects) and not native types int, boolean, double... So you are likely better to just use the object types for HE.
Another good thing to watch is if() statements where () does not return a boolean - this causes the compiler to generate a lot of 'box'/casting code that slows things down.
The above along with good usage of void vs. other return types for methods can help performance (and I'm guessing code size).
Also, using state, or atomicState less (less size, less accesses), is always a good thing, along with avoiding log.xxxx messages (which also go to the db)
@nh.schottfam and @mike.maxwell thank you, all this is great to know, I'm sure I can improve my apps and drivers applying this information.
I'll give that a go, I've also been thinking of integrating unit testing into my workflow. I've really been missing that when working with HE...
This is a good point, I've been trying to make sure I do this explicitly, but it's a habit hard to break sometimes, usually I fix it at my second pass of the code.
This is something I've been starting to be more careful with, but how much of a performance difference does this account for?
atomicState I don't use if I can avoid it, and state I try to limit by design, but there more could be done I'm sure...
