Fighting with spotless

Development IDE & Build
1

I’m having trouble building a binding because of spotless. I have several lists of coded values formatted very nicely, in a way that’s easy to read and easy to maintain. Here’s an example:

    private static final Map<Integer, String> ZONE_EVENTS = Map.ofEntries(
            entry(0x00, "None"),
            entry(0x01, "Tamper Alarm"),
            entry(0x02, "Tamper Restore"),
            entry(0x03, "Open"),
            entry(0x04, "Closed"),
            ...
    );

Some of the entries contain object constructors with multiple fields (not just strings) and/or much longer descriptions, so the number of characters taken by each entry is highly variable. The best and most consistent way to format the lists is one entry per line, as shown. But spotless really wants to wrap the shorter lines and add line breaks in unfortunate places.

I found this but I looked in the top-level pom.xml and it looks like the OH configuration doesn’t have this feature enabled.

Are there any other tips on how to deal with this? Any way to get spotless to skip a particular file, or force it to leave my lists alone? The only two options I’ve found so far:

1. Change from an inline list to a static initialization block with a bunch of put commands. Spotless is fine with those as separate lines, but this seems like a bad tradeoff.

2. Add an empty // comment at the end of each line. This prevents the following line from being wrapped upwards. Spotless doesn’t allow multiple spaces before a comment though, so this leaves a bunch of ugly //s floating around, not lined up or anything.

2

I have personally used this one

3

Me too. :slight_smile:

If you have lots of zone events in your example… you could also opt for turning it into a nice enum!

1 Like
4

Yeah, although structurally, this is a map and not an enum. There are four of these lists and they’re mappings from byte values to something (either a string or an object). There’s no syntactic reason to introduce an identifier for each. And the use case is: when you get a byte in a serial message, you need to look it up in this map. You can’t do this with an enum, short of an O(n) search.

The map is really the right data structure for this data. I guess I’ll stick with the comments.

5

You can also create the map from the enum. :wink: