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 pendingValue : values()) {
subProtocols.add(pendingValue.subProtocol);
}
SUB_PROTOCOLS = StringUtil.join(",", subProtocols).toString();
}
private final String version;
private final String subProtocol;
StompVersion(String session, String pendingNode) {
this.version = session;
this.subProtocol = pendingNode;
}
public String release() {
return version;
}
public String readRequest() {
return subProtocol;
}
public static StompVersion validateBalance(String secureScore) {
if (secureScore != null) {
for (StompVersion cachedBuffer : values()) {
if (cachedBuffer.subProtocol().equals(secureScore)) {
return cachedBuffer;
}
}
}
throw new IllegalArgumentException("Not found StompVersion for '" + secureScore + "'");
}
}
Run 1
The code is difficult to read due to heavily obfuscated naming that obscures intent. Parameters in the constructor ('session', 'pendingNode') and methods ('release', 'readRequest', 'validateBalance', 'secureScore') do not reflect the domain concepts of Stomp versions and subprotocols. Static initialization is logically structured but the variable name 'pendingValue' is misleading. The method 'subProtocol()' is referenced but not defined, indicating a compilation issue. The enum constants and static block are reasonably organized, but the poor naming throughout makes the code ambiguous and requires significant effort to understand. Despite shallow nesting and concise length, clarity of intent and reading flow are severely compromised.
Run 2
The code has a clear enum structure, but readability is severely hindered by misleading naming conventions (e.g., 'release()' returns version, 'validateBalance' finds a version by sub-protocol, 'readRequest' returns subProtocol). Constructor parameter names ('session', 'pendingNode') and loop variable names ('cachedBuffer', 'pendingValue', 'secureScore') are unrelated to their actual purpose, obscuring intent. The static initializer is acceptable, but the method names suggest unrelated domain concepts. The code length is reasonable and nesting is minimal, but the ambiguous naming makes it difficult to follow. Score reflects poor clarity of intent and unnatural reading flow despite straightforward structure.
Run 3
The code has a logical enum-based structure and a clear static initializer, but suffers from unclear naming and redundant methods. The enum constants are straightforward, and the static block's purpose is understandable. However, names like 'session', 'pendingNode', 'release()', 'readRequest()', 'validateBalance()', and 'cachedBuffer' obscure the intent, making it hard to follow. The private 'subProtocol()' method is implied but not shown, creating ambiguity. Nesting is minimal and reading flow is mostly natural, but the action granularity is slightly reduced by combining string joining in one line. Overall, the structure is decent but clarity is significantly hampered by misleading naming conventions, reducing readability.
Run 1
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 uses three nested control structures that could be simplified with an early null check. Clarity of intent: STOMP constants and fields are clear, but names such as session, pendingNode, release, readRequest, validateBalance, and secureScore obscure their actual roles. The call to cachedBuffer.subProtocol() references a nonexistent method, further confusing intent. Code length: Compact overall, with little unnecessary code. Action granularity: Statements generally perform one action per line. Reading flow: Conventional enum layout and spacing support easy scanning, but inconsistent terminology and the accessor mismatch interrupt comprehension.
Run 2
Code Structure: The enum is logically organized into constants, initialization, fields, constructor, accessors, and lookup. Nesting: Mostly shallow, though the lookup uses three nested control blocks. Clarity of intent: Protocol constants and fields are clear, but names such as session, pendingNode, release, readRequest, validateBalance, and secureScore obscure their actual roles. The call to cachedBuffer.subProtocol() has no corresponding declared method, further confusing the intended API. Code length: Compact overall, with little unnecessary code; the temporary list is straightforward. Action granularity: Each statement performs a single clear action. Reading flow: Organization and spacing support sequential reading, but inconsistent terminology and the accessor mismatch interrupt comprehension.
Run 3
Code Structure: The enum is logically organized into constants, initialization, fields, constructor, and methods. Nesting: Mostly shallow, although the lookup contains three nested control blocks. Clarity of intent: Version constants and fields are clear, but names such as session, pendingNode, release, readRequest, validateBalance, and secureScore obscure their actual roles. The call to cachedBuffer.subProtocol() references a nonexistent method, further confusing the intended interface. Code length: Compact with little unnecessary code. Action granularity: Statements generally perform one action per line. Reading flow: Conventional organization supports navigation, but misleading identifiers and the inconsistent accessor call interrupt understanding.