How to Lint Hubitat Groovy code?

Hello community.

I am primarily a Java developer. I have learned a lot of Groovy, and keep learning more every day. One challenge I have is validating my code reliably. Static analysis tools are abundant in the Java world, and I have even located one for Groovy that is a plug-in for Microsoft VSCode.

What are you guys using to validate your code, and check for common mistakes in code? The generic Groovy linters are not well adapted for Hubitat or ST development given that our groovy files are not true groovy from what I can tell, but rather a type of object class definition supplemented with concrete functions.

This makes it challenging, since the preferences, and metadata create weird behavior in the linter. In addition, the general use of "def" for defining a function or variable loosely results in a lot of warning in the linter. Sure, I can ignore a lot of these, but I am curious what others are using.

1 Like

There is not much out there, the only thing that I know of is this: GitHub - gtg465x/hubitat-source-stub

Personally have not tested because I use an extra Hub for development, but it could be a good start. Additionally there is not real / good groovy IDE.. or at least for VSCode.

Good coding :wink:

1 Like

I use intellij

Also see

Dev hub
Extensive testing
LOADS of debug code initially
Beta testers

:slight_smile:

Andy

100% agree there.. When I was learning groovy driver development, I made a mess of my hub.. With a dev hub you can make all the mistakes you need to in the learning process without lowering the WAF :wink:

4 Likes

Anyway we can convert this into an app or something so it can lint application codes maybe for developers?

https://nvuillam.github.io/npm-groovy-lint/

I've recently started maintaining my code in VS Code and installed a lint add-on (Groovy Lint, format and fix - looks like it is the same one linked above by @saurabh9), but it does bring up a lot of warnings, so kind of off-putting to continue to use it. That may say more about my code than the add-on... I started to try and adopt some of the recommendations it was making as they semed reasonable, like strongly typing variables / parameters and method returns, etc. But some of the suggestions around literals that are used more than once is a bit over the top. That said, I haven't delved into the settings to try and cut down some of the noise.

Simon

The issue with repetitive literals is that in groovy they are actually reappeared in memory, whereas in Java, duplicate literals are normalized, creating a single instance. This is a memory issue. If you repeat the same literal more than once, assign it to a variables and reference the variable. It saves memory and does not slow things down at all.

1 Like

Thanks, I wasn't aware of that....

I guess my gripe, with the extension (not you :slight_smile:), is that some relatively simple literals used twice trigger the warning. I get the general idea with what you are describing, and can appreciate it may make a difference either in methods that have a number of uses for the same literal, or are called repeatedly, but there are some circumstances where I expect the effect is inconsequential.

Anyway, now I'm being defensive towards someone simply try to provide some constructive, useful advice. I should be appreciative.... I will bear this in mind when I make my next update to my drivers :slight_smile: , and probably update my code....

Thanks,
Simon

Intellij works very well for this.

2 Likes

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.