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 stompVersion : values()) {
subProtocols.add(stompVersion.subProtocol);
}
SUB_PROTOCOLS = StringUtil.join(",", subProtocols).toString();
}
private final String version;
private final String subProtocol;
StompVersion(String version, String subProtocol) {
this.version = version;
this.subProtocol = subProtocol;
}
public String version() {
return version;
}
public String subProtocol() {
return subProtocol;
}
public static StompVersion findBySubProtocol(String subProtocol) {
if (subProtocol != null) {
for (StompVersion stompVersion : values()) {
if (stompVersion.subProtocol().equals(subProtocol)) {
return stompVersion;
}
}
}
throw new IllegalArgumentException("Not found StompVersion for '" + subProtocol + "'");
}
}
Run 1
The code is well-structured, with a logical enum layout: constants first, then static fields, constructor, accessor methods, and a lookup method. Nesting is minimal, with only a single loop inside the static initializer and lookup method. Intent is clear: each enum constant maps a STOMP version to its subprotocol, and the static block builds a comma-separated list for registration. Code length is appropriate for the functionality, and actions are granular, one per line. Reading flow is natural and easy to follow. Minor deductions: the static initializer could be more concise with streams, and error handling in findBySubProtocol is slightly abrupt, but overall readability is excellent.
Run 2
The code is well-structured with a clear enum pattern. The static initializer blocks are logically organized, and the class maintains a clean separation of concerns. Nesting is minimal—the deepest nesting is a single if-statement within a for-loop in findBySubProtocol, which is acceptable. Intent is clearly communicated through descriptive method names and constants. The code is concise without sacrificing clarity; the static block for building SUB_PROTOCOLS is idiomatic. Action granularity is good, with one logical operation per line. Reading flow is natural: constants, static initialization, fields, constructor, accessors, then utility method. Minor improvements could include using `String.join` (though the internal utility is appropriate for Netty) and perhaps adding method-level documentation, but these are negligible. Overall, this is highly readable code.
Run 3
The code is well-structured and readable. The enum is logically organized with constants, static fields, constructor, and methods in a clear order. Nesting is minimal, with only a single-level static block and null check. Intent is clear: define STOMP versions, their subprotocols, and lookup functionality. The code is concise without being overly compressed. Each action is granular, with one operation per line in most cases. Reading flow is natural, from constants to initialization to accessors to lookup logic. Minor deductions: the static block's use of StringUtil.join requires knowledge of Netty internals, and the generic type parameter on ArrayList is slightly verbose, but these don't significantly impact readability.
Run 1
Code Structure: The enum logically groups protocol constants, initialization, fields, constructor, accessors, and lookup behavior. Nesting: Most code is flat, but findBySubProtocol has three nested control levels; an early null check could simplify it. Clarity of intent: Descriptive names and immutable fields make the purpose clear. Code length: Compact and appropriate, with little unnecessary code. Action granularity: Statements generally perform one action per line, and assignments and returns are easy to follow. Reading flow: Conventional ordering and consistent formatting support natural reading, though spacing between the package declaration and imports would improve visual separation. Overall, highly readable with minor opportunities to flatten the lookup method and polish formatting.
Run 2
Code Structure: The enum logically groups supported versions, shared constants, initialization, fields, accessors, and lookup behavior. Nesting: Most code is flat, though the lookup contains three nested control structures that could be simplified with an early null check. Clarity of intent: Descriptive names and straightforward operations clearly communicate version-to-subprotocol mapping and lookup. Code length: Concise overall, with only minor verbosity in constructing the protocol list. Action granularity: Each statement performs a distinct action, with no crowded multi-statement lines. Reading flow: Consistent formatting and conventional ordering make the code easy to follow; the static initializer preceding instance fields creates only a minor forward-reference interruption.
Run 3
Code Structure: The enum is logically organized into constants, static initialization, fields, constructor, accessors, and lookup method. Nesting: Most code is flat, but the lookup method nests a loop and conditional inside a null check; an early guard could simplify it. Clarity of intent: Descriptive names clearly express version mappings, subprotocol aggregation, and lookup behavior. Code length: Compact and appropriate, with little unnecessary code. Action granularity: Each statement performs one clear action, and assignments and control flow are separated cleanly. Reading flow: Consistent formatting and conventional organization make the code easy to follow, though the static initialization before instance fields slightly interrupts the progression from data declaration to behavior.