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 a : values()) {
subProtocols.add(a.subProtocol);
}
SUB_PROTOCOLS = StringUtil.join(",", subProtocols).toString();
}
private final String version;
private final String subProtocol;
StompVersion(String b, String c) {
this.version = b;
this.subProtocol = c;
}
public String a() {
return version;
}
public String b() {
return subProtocol;
}
public static StompVersion c(String d) {
if (d != null) {
for (StompVersion e : values()) {
if (e.subProtocol().equals(d)) {
return e;
}
}
}
throw new IllegalArgumentException("Not found StompVersion for '" + d + "'");
}
}
Run 1
The code has a reasonably clear structure and moderate length, but it suffers from severe readability issues due to poor naming and intentional obfuscation. Method names like 'a()', 'b()', and 'c()' and parameter names like 'b', 'c', and 'd' make the code extremely ambiguous and hard to follow. The field names 'version' and 'subProtocol' are clear, but the constructor parameters do not match them, hurting clarity. Additionally, the static initialization block and the c() method are flat and reasonably structured, but the ambiguous naming undermines readability. The code layout is acceptable but the deliberate use of meaningless identifiers drastically reduces its clarity and maintainability.
Run 2
The code follows a standard enum structure with constants and a static initializer, which is good. However, it uses single-letter method and parameter names (a, b, c, d, e) which obscure intent. Import placement and spacing are inconsistent. The loop in the static block and the lookup method are straightforward, but the overall readability is hurt by ambiguous naming and lack of Javadoc. Nesting is minimal, but the code lacks clarity in purpose.
Run 3
This code is heavily obfuscated and difficult to read. The structure is logical but obscured by meaningless names: methods a(), b(), c(), constructor parameters b and c, and local variables d, e. The static initializer is acceptable but nested within an otherwise confusing enum. Clarity of intent is severely damaged—method a() returns version, b() returns subProtocol, and c() performs a lookup, but none of these names communicate their purpose. The code length is reasonable, but action granularity is mostly fine; however, reading flow is unnatural because the reader must decode every identifier. Nesting is shallow, which is good, but not enough to recover readability. Variables like 'a' in the loop are meaningless. The class appears intentionally obfuscated (e.g., a(), b(), c()), which drops readability dramatically. Even the constructor parameters 'b' and 'c' hide meaning. Overall, the structure is not tangled, but the naming kills clarity and maintainability.
Run 1
Code Structure: The enum is logically organized into constants, initialization, fields, constructor, accessors, and lookup. Nesting: Most code is flat, but the lookup uses three nested levels that could be reduced with an early null check. Clarity of intent: STOMP constants and field names convey purpose, but single-letter parameters and methods obscure the API. The call to e.subProtocol() has no matching method in the snippet, creating additional confusion. Code length: Compact overall, with little unnecessary code. Action granularity: Statements generally perform one action per line. Reading flow: Conventional ordering and whitespace support scanning, but ambiguous names and the inconsistent accessor call interrupt comprehension.
Run 2
Code Structure: The enum logically groups protocol constants, initialization, fields, accessors, and lookup behavior. Nesting: Initialization is shallow, but lookup has three nested control levels that could be simplified with a guard clause. Clarity of intent: Descriptive constants and fields help, but single-letter method names, parameters, and loop variables obscure meaning. The lookup calls subProtocol(), which is not defined; the corresponding accessor is named b(), creating an inconsistency that interrupts comprehension. Code length: Compact and mostly proportionate to its purpose. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Conventional organization and spacing support scanning, but cryptic naming and the accessor mismatch force readers to infer relationships and revisit declarations.
Run 3
Code Structure: The enum logically groups protocol constants, initialization, fields, accessors, and lookup behavior. Nesting: Initialization is shallow, but lookup uses three nested control blocks where a guard clause could simplify reading. Clarity of intent: Descriptive fields and constants help, but single-letter method names, parameters, and loop variables obscure purpose. The lookup calls subProtocol(), which is not defined; the corresponding accessor is named b(), creating a confusing inconsistency. Code length: Compact and mostly necessary, with little redundant code. Action granularity: Statements generally perform one action per line. Reading flow: The overall ordering is conventional, but ambiguous names and the accessor mismatch interrupt comprehension.