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 has severe readability issues. Multiple statements are compressed onto single lines, making visual scanning difficult. The static initialization block is particularly problematic, with a for-loop body and variable declaration crammed together. Method bodies are inconsistently formatted - some spread across lines while others are one-liners. The static block's logic is also unnecessarily verbose: it manually builds a list and then joins it instead of using a simpler stream approach. The enum structure itself is logical, but the field declarations and the AttributeKey constant lack spacing and separation. Import statements are compressed. The findBySubProtocol method violates action granularity, as the closing method braces and adjacent methods share lines. Overall, this code appears functional but formatted in a way that significantly impairs quick comprehension and maintainability.
Run 2
The code has significant readability issues. The structure is compressed with multiple declarations and statements on single lines, making it hard to scan. Nesting is shallow, which is good, but the density undermines clarity. Intent is mostly clear (enum representing STOMP versions with sub-protocol mapping), but the formatting obscures it. Code length is reasonable, but action granularity is poor—multiple actions share lines, reducing scannability. Reading flow is disrupted by inconsistent spacing and line breaks, forcing the reader to mentally decode the code. While the logic itself is straightforward, the presentation makes it feel tangled and error-prone to navigate.
Run 3
The code has significant readability issues. Structure and formatting are poor: multiple statements are packed onto single lines, enum constants are separated oddly, and indentation is inconsistent. Nesting is minimal, which is good, but action granularity suffers from multiple actions on one line. Clarity of intent is somewhat preserved by method names, but mangled formatting obscures the logical flow. Code length is acceptable for the task, but the static block and constant definitions feel cluttered. Reading flow is disorganized due to erratic line breaks and inconsistent spacing. Overall, the intent is understandable but the presentation severely degrades readability.
Run 1
Code Structure: The enum logically groups constants, initialization, fields, and lookup behavior, but compressed formatting obscures member boundaries. Nesting: Most code is shallow; the lookup method has three nested control-flow levels, which remain manageable. Clarity of intent: Descriptive names and straightforward operations clearly convey version metadata and subprotocol lookup. Code length: The implementation is concise without substantial redundancy. Action granularity: Several lines combine declarations, method definitions, or control flow with actions, making individual operations harder to distinguish. Reading flow: Inconsistent line breaks, inline closing braces, and adjacent methods interrupt otherwise natural top-to-bottom organization. Conventional formatting would substantially improve readability without changing the logic.
Run 2
Code Structure: The enum logically groups constants, initialization, fields, and methods, but compressed formatting obscures boundaries. Nesting: Most code is shallow; the lookup method has three nested control-flow levels, which remain manageable. Clarity of intent: Descriptive names and straightforward logic clearly communicate protocol versions and lookup behavior. Code length: The implementation is concise without substantial unnecessary code. Action granularity: Several lines combine declarations, statements, or entire methods, making individual actions harder to scan. Reading flow: Inconsistent line breaks, inline closing braces, and adjacent method declarations disrupt otherwise natural organization. Overall, the logic is readable, but formatting significantly reduces readability.
Run 3
Code Structure: The enum logically groups protocol constants, initialization, fields, accessors, and lookup behavior, but inconsistent formatting obscures those boundaries. Nesting: Most methods are flat; the lookup has moderate nesting through a null check, loop, and conditional. Clarity of intent: Descriptive names and straightforward operations clearly convey version mapping and subprotocol lookup. Code length: The implementation is concise without substantial redundancy. Action granularity: Several lines combine unrelated declarations, statements, or method boundaries, making individual actions harder to distinguish. Reading flow: Conventional member ordering helps, but crowded lines, irregular brace placement, and uneven spacing interrupt scanning. Overall, the logic is easy to understand, while formatting noticeably reduces readability.