Sample

int-fc1d089ea327-I04

Replace method, parameter, and local names with deterministic ProGuard-style short identifiers

Matched original source

Lines109

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.6280–1; higher is more readable
Dorn0.3050–1; higher is more readable
Mi0.5730–1; higher is more readable
LLOC36Logical lines; fewer is more readable
DeepSeek V4 Pro4.330–20; mean of three runs
GPT-6.1 Sol110–20; mean of three runs
BTTF0.390–1; higher is more readable

Views

Source code

package org.springframework.web.socket.sockjs.transport.handler; import java.io.IOException; import java.nio.charset.StandardCharsets; import java.util.regex.Pattern; import org.jspecify.annotations.Nullable; import org.springframework.http.MediaType; import org.springframework.http.server.ServerHttpRequest; import org.springframework.http.server.ServerHttpResponse; import org.springframework.util.MultiValueMap; import org.springframework.util.StringUtils; import org.springframework.web.socket.WebSocketHandler; import org.springframework.web.socket.sockjs.SockJsException; import org.springframework.web.socket.sockjs.frame.SockJsFrame; import org.springframework.web.socket.sockjs.frame.SockJsFrameFormat; import org.springframework.web.socket.sockjs.transport.SockJsSession; import org.springframework.web.socket.sockjs.transport.SockJsSessionFactory; import org.springframework.web.socket.sockjs.transport.session.AbstractHttpSockJsSession; import org.springframework.web.util.UriComponentsBuilder; import org.springframework.web.util.UriUtils; /** * Base class for HTTP transport handlers that push messages to connected clients. * * @author Rossen Stoyanchev * @since 4.0 */ public abstract class AbstractHttpSendingTransportHandler extends AbstractTransportHandler implements SockJsSessionFactory { /** * Pattern for validating callback parameter values. */ private static final Pattern CALLBACK_PARAM_PATTERN = Pattern.compile("[0-9A-Za-z_.]*"); @Override public final void a(ServerHttpRequest a, ServerHttpResponse b, WebSocketHandler c, SockJsSession d) throws SockJsException { AbstractHttpSockJsSession e = (AbstractHttpSockJsSession) d; // https://github.com/sockjs/sockjs-client/issues/130 // sockJsSession.setAcceptedProtocol(protocol); // Set content type before writing b.getHeaders().setContentType(d()); b(a, b, e); } protected void b(ServerHttpRequest f, ServerHttpResponse g, AbstractHttpSockJsSession h) throws SockJsException { if (h.isNew()) { if (logger.isDebugEnabled()) { logger.debug(f.getMethod() + " " + f.getURI()); } h.handleInitialRequest(f, g, e(f)); } else if (h.isClosed()) { if (logger.isDebugEnabled()) { logger.debug("Connection already closed (but not removed yet) for " + h); } c(SockJsFrame.closeFrameGoAway(), f, g, h); } else if (!h.isActive()) { if (logger.isTraceEnabled()) { logger.trace("Starting " + getTransportType() + " async request."); } h.handleSuccessiveRequest(f, g, e(f)); } else { if (logger.isDebugEnabled()) { logger.debug("Another " + getTransportType() + " connection still open for " + h); } c(SockJsFrame.closeFrameAnotherConnectionOpen(), f, g, h); } } private void c(SockJsFrame i, ServerHttpRequest j, ServerHttpResponse k, AbstractHttpSockJsSession l) { String m = e(j).format(i); try { k.getBody().write(m.getBytes(SockJsFrame.CHARSET)); } catch (IOException n) { throw new SockJsException("Failed to send " + m, l.getId(), n); } } protected abstract MediaType d(); protected abstract SockJsFrameFormat e(ServerHttpRequest o); protected final @Nullable String f(ServerHttpRequest p) { String q = p.getURI().getQuery(); MultiValueMap<String, String> r = UriComponentsBuilder.newInstance().query(q).build().getQueryParams(); String s = r.getFirst("c"); if (!StringUtils.hasLength(s)) { return null; } String t = UriUtils.decode(s, StandardCharsets.UTF_8); return (CALLBACK_PARAM_PATTERN.matcher(t).matches() ? t : null); } }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(log-odds)
Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones.5019.105−165.63
Source linesThe number of non-empty source lines.109+43.6
Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value.5.174−7.761

Intercept 8.87 + feature contributions = -120.921 (log-odds).
Score = sigmoid(-120.921) = 0.

Score0.628

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.110−2.858
Indentation frequencyHow rapidly indentation changes from line to line.99+2.687
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.99−1.851
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.108.925+1.113
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.104.982+0.889
Identifier layout (horizontal)How rapidly the visual pattern of identifier characters changes from left to right. It measures spatial frequency, not the meaning of the names.104.964−0.781
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.106−0.091

Intercept 0.07 + feature contributions = -0.821 (log-odds).
Score = sigmoid(-0.821) = 0.305.

Score0.573
Score36
Run 1

The code is nearly unreadable due to the systematic replacement of all method and variable names with single letters (a, b, c, d, etc.). This obliterates clarity of intent, making it impossible to discern what each method does without deep analysis. The structure and logical organization are also lost, and the natural reading flow is completely disrupted. While the nesting level is moderate and the code is concise, the obfuscation of names renders the code ambiguous and impenetrable. A developer would struggle to understand the purpose of methods like 'a()' or 'e()', and the flow of arguments between them is a tangled mess. Action granularity is acceptable, but insufficient to rescue the overall unreadability caused by the cryptic naming.

Run 2

This code is severely obfuscated and essentially unreadable. Method names have been replaced with meaningless single letters (a, b, c, d, e, f), as have parameters (a through t). This destroys clarity of intent, making it impossible to understand what each method or variable does without external documentation. The reading flow is completely unnatural, forcing the reader to decipher single-letter identifiers. While the code structure and nesting are technically preserved from the original, the renaming erases any logical organization conveyed by naming. Action granularity is okay, but any benefit is lost due to the meaningless names. Code length is unchanged, but conciseness here just means terse, confusing code. It fails practically all readability criteria.

Run 3

The code suffers from severely poor readability due to meaningless single-letter method and parameter names (a, b, c, d, e, f, etc.) that completely obscure intent. While the structure and nesting are relatively flat and actions are mostly one per line, the obfuscated naming makes understanding the flow extremely difficult. The method `a` calls `b`, which calls `c`, `d`, `e`, and `f`, requiring constant mental mapping. There is no clear indication of what these methods do. The only clarity comes from comments and the original method signatures, but the implementation details are hidden behind cryptic identifiers. This violates the 'Clarity of intent' and 'Reading flow' criteria severely. The code is technically well-structured and concise, but practically unreadable without extensive effort to rename identifiers. Overall, it reads like heavily obfuscated code, likely from a decompilation or intentional minification, making it very difficult to maintain or review.

Run 1

Code Structure: Responsibilities are logically separated into request dispatch, session-state handling, frame writing, and callback validation. Nesting: Mostly shallow, with straightforward conditionals and limited nested logging checks. Clarity of intent: Severely weakened by single-letter method and variable names; types, API calls, and comments provide some context, but readers must repeatedly infer each identifier's role. Code length: Generally concise, although obsolete commented-out code and excessive blank lines add minor clutter. Action granularity: Most statements perform one action; a few chained expressions combine parsing or formatting steps but remain manageable. Reading flow: The session-state branches follow a natural sequence, and helper methods support the main logic, but ambiguous names and similarly named methods and parameters interrupt comprehension.

Run 2

Code Structure: Responsibilities are separated into request handling, frame writing, and callback extraction, with a logical class layout. Nesting: Shallow conditional branches and small logging blocks are easy to follow. Clarity of intent: Single-letter method and variable names severely obscure responsibilities and require repeatedly inferring meaning from types and calls; descriptive framework APIs and comments partially compensate. Code length: Methods are short and reasonably concise, although obsolete commented-out code adds noise. Action granularity: Most statements perform one action, while chained query parsing and inline formatting combine several operations. Reading flow: The session-state branch sequence is natural, but cryptic calls such as b(a, b, e) and e(j) interrupt comprehension. Overall, sound organization and manageable complexity are undermined primarily by poor naming.

Run 3

Code Structure: Methods logically separate request dispatch, session-state handling, frame writing, and callback validation. Nesting: Mostly shallow, with a clear conditional chain and modestly nested logging checks. Clarity of intent: Severely weakened by single-letter method and variable names; readers must infer roles from types and calls. Descriptive framework APIs, documentation, and error messages partially compensate. Code length: Reasonably concise, although an obsolete commented-out call and extra blank lines add noise. Action granularity: Generally one action per statement, with a few chained expressions that remain manageable. Reading flow: The progression from entry point to helpers is natural, but cryptic identifiers, especially method names shared with parameter names, repeatedly interrupt comprehension.