Source code
package io.netty.example.stomp.websocket;
import io.netty.util.AttributeKey;
import io.netty.util.internal.StringUtil;
import java.util.ArrayList;
import java.util.List;
public enum StompVersion {
STOMP_V11("1.1", "v11.stomp"),
STOMP_V12("1.2", "v12.stomp");
public static final AttributeKey<StompVersion> CHANNEL_ATTRIBUTE_KEY = AttributeKey.valueOf("stomp_version");
public static final String SUB_PROTOCOLS;
static {
List<String> subProtocols = new ArrayList<String>(values().length);
for (StompVersion stomp2 : values()) {
subProtocols.add(stomp2.subProtocol);
}
SUB_PROTOCOLS = StringUtil.join(",", subProtocols).toString();
}
private final String version;
private final String subProtocol;
StompVersion(String ver, String sub) {
this.version = ver;
this.subProtocol = sub;
}
public String ver() {
return version;
}
public String sub() {
return subProtocol;
}
public static StompVersion find(String sub2) {
if (sub2 != null) {
for (StompVersion stomp3 : values()) {
if (stomp3.subProtocol().equals(sub2)) {
return stomp3;
}
}
}
throw new IllegalArgumentException("Not found StompVersion for '" + sub2 + "'");
}
}
Run 1
The code is generally readable and well-structured. The enum constants and fields are clear, and the static initializer for SUB_PROTOCOLS is straightforward. However, several issues reduce readability: the variable names 'stomp2' and 'stomp3' are awkward and could be 'version' or 'stompVersion'; the constructor parameter names 'ver' and 'sub' are unnecessarily abbreviated; method names 'ver()' and 'sub()' are cryptic compared to 'version()' and 'subProtocol()'; the static block mixes collection building and string joining without a clear separation of concerns; and the find() method uses an imperative loop where a stream with filter/findFirst would be more concise. Overall, the code is maintainable but would benefit from better naming and slightly more modern idioms.
Run 2
The code is well-structured and generally readable. It follows a logical enum pattern with clear separation of constants, static initialization, fields, constructor, and methods. Nesting is minimal, with only one level inside the static block and find method. Intent is clear: defining STOMP protocol versions and providing a lookup mechanism. Code length is concise, though some variable names like 'stomp2', 'stomp3', 'sub2', and parameter names 'ver', 'sub' are less descriptive. Action granularity is good, with one operation per line. Reading flow is natural, moving from enum constants to static members, then to instance methods and static utility methods. The naming inconsistency in loop variables and abbreviated method parameters slightly reduces clarity compared to the otherwise clean implementation.
Run 3
The code is well-structured and readable. The enum pattern is clear, with constants, static initialization, instance fields, and methods logically organized. Nesting is minimal with only one level in the static block and find method. Variable names like 'stomp2', 'stomp3', 'sub', and 'ver' are unnecessarily abbreviated, reducing clarity. The static initializer is concise but could use a stream for better flow. Action granularity is generally good, though the loop in static initialization packs iteration and addition into one line. The find method's null check and loop flow naturally, and the exception message is clear. Overall, the code is concise and maintainable with minor naming improvements possible.
Run 1
Code Structure: The enum is logically organized into constants, initialization, fields, constructor, accessors, and lookup. Nesting: Most code is flat, but find has three nested control structures; an early null check could simplify it. Clarity of intent: Version-to-subprotocol mapping is clear, but abbreviated names such as ver, sub, sub2, stomp2, and stomp3 reduce precision. The call to subProtocol() has no corresponding method in the snippet, creating confusion and a compilation error. Code length: Compact overall, with little unnecessary code. Action granularity: Statements generally perform one action per line. Reading flow: Organization and spacing support a natural reading order, although inconsistent accessor naming and numbered variable names interrupt comprehension.
Run 2
Code Structure: The enum is logically organized into constants, static initialization, fields, constructor, accessors, and lookup. Nesting: Most code is flat, but find uses three nested control structures where a guard clause could simplify it. Clarity of intent: Version and subprotocol mapping is understandable, but abbreviated names (ver, sub) and numbered variables (stomp2, stomp3, sub2) reduce clarity. The call to subProtocol() has no corresponding accessor, creating an inconsistency that interrupts understanding. Code length: Compact overall, with little unnecessary code. Action granularity: Statements generally perform one action per line. Reading flow: Organization and spacing support natural reading, though inconsistent naming and the missing accessor weaken continuity.
Run 3
Code Structure: The enum is logically organized into constants, initialization, fields, constructor, and methods. Nesting: Most code is flat, but find() nests a loop and condition inside a null check. Clarity of intent: Version and subprotocol mapping is understandable, but abbreviated methods and parameters (ver, sub, sub2) and numbered variables (stomp2, stomp3) weaken clarity. The call to subProtocol() has no corresponding method; the defined accessor is sub(), creating confusion. Code length: Compact overall, with little unnecessary code. Action granularity: Statements generally perform one action per line. Reading flow: Declaration order and formatting are natural, though inconsistent accessor naming interrupts comprehension.