Sample

int-aabcd3612d29-I10

Remove about 40% of line-break groups while retaining structure

Matched original source

Lines72

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.3360–1; higher is more readable
Dorn0.0080–1; higher is more readable
Mi00–1; higher is more readable
LLOC36Logical lines; fewer is more readable
DeepSeek V4 Pro90–20; mean of three runs
GPT-6.1 Sol110–20; mean of three runs
BTTF0.1790–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 handleRequest(ServerHttpRequest request, ServerHttpResponse response, WebSocketHandler wsHandler, SockJsSession wsSession) throws SockJsException { AbstractHttpSockJsSession sockJsSession = (AbstractHttpSockJsSession) wsSession; // https://github.com/sockjs/sockjs-client/issues/130 // sockJsSession.setAcceptedProtocol(protocol); // Set content type before writing response.getHeaders().setContentType(getContentType()); handleRequestInternal(request, response, sockJsSession); } protected void handleRequestInternal(ServerHttpRequest request, ServerHttpResponse response, AbstractHttpSockJsSession sockJsSession) throws SockJsException { if (sockJsSession.isNew()) { if (logger.isDebugEnabled()) { logger.debug(request.getMethod() + " " + request.getURI()); } sockJsSession.handleInitialRequest(request, response, getFrameFormat(request)); } else if (sockJsSession.isClosed()) { if (logger.isDebugEnabled()) { logger.debug("Connection already closed (but not removed yet) for " + sockJsSession); } writeFrame(SockJsFrame.closeFrameGoAway(), request, response, sockJsSession); } else if (!sockJsSession.isActive()) { if (logger.isTraceEnabled()) { logger.trace("Starting " + getTransportType() + " async request."); } sockJsSession.handleSuccessiveRequest(request, response, getFrameFormat(request)); } else { if (logger.isDebugEnabled()) { logger.debug("Another " + getTransportType() + " connection still open for " + sockJsSession); } writeFrame(SockJsFrame.closeFrameAnotherConnectionOpen(), request, response, sockJsSession); } } private void writeFrame(SockJsFrame frame, ServerHttpRequest request, ServerHttpResponse response, AbstractHttpSockJsSession sockJsSession) { String formattedFrame = getFrameFormat(request).format(frame); try { response.getBody().write(formattedFrame.getBytes(SockJsFrame.CHARSET)); } catch (IOException ex) { throw new SockJsException("Failed to send " + formattedFrame, sockJsSession.getId(), ex); } } protected abstract MediaType getContentType(); protected abstract SockJsFrameFormat getFrameFormat(ServerHttpRequest request); protected final @Nullable String getCallbackParam(ServerHttpRequest request) { String query = request.getURI().getQuery(); MultiValueMap<String, String> params = UriComponentsBuilder.newInstance().query(query).build().getQueryParams(); String value = params.getFirst("c"); if (!StringUtils.hasLength(value)) { return null; } String result = UriUtils.decode(value, StandardCharsets.UTF_8); return (CALLBACK_PARAM_PATTERN.matcher(result).matches() ? result : 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.4989.917−164.667
Source linesThe number of non-empty source lines.72+28.8
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.083−7.624

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

Score0.336

Feature contributions

FeatureValueContribution
(log-odds)
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.279−8.152
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.279+3.697
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.73−1.548
Indentation frequencyHow rapidly indentation changes from line to line.62+1.407
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.62−1.002
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.71.904+0.595
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.091+0.061

Intercept 0.07 + feature contributions = -4.872 (log-odds).
Score = sigmoid(-4.872) = 0.008.

Score0
Score36
Run 1

The code demonstrates good structure with clear method separation and proper Spring patterns. Class organization is logical with methods grouped by functionality. Nesting is moderate - the deepest levels occur in handleRequestInternal with if-else chains but remain manageable. Intent clarity is strong, with descriptive method names like writeFrame and getCallbackParam. Code length is appropriate; no unnecessary verbosity beyond framework requirements. Action granularity is mostly one-action-per-line, though some imports are compressed and a few statements are packed together. Reading flow follows natural progression from request handling to frame writing to utilities. Main readability issues: inconsistent formatting (multiple imports on single lines, collapsed braces in places, variable declaration and immediate use on same line), long method signatures, and some dense conditional blocks. Overall, the code is maintainable and understandable for experienced Spring developers, but formatting inconsistencies slightly reduce its readability score.

Run 2

The code's logical structure is mostly clear, but formatting is severely compromised by multiple statements on single lines and imports crammed together, directly hurting readability. Nesting is moderate but made harder to follow due to compressed conditional blocks. Intent is understandable for a Spring transport handler, but the collapsed code forces readers to work harder to parse branches. Code length is not inherently excessive, yet the formatting makes it feel dense and discourages scanning. Action granularity is poor—many lines contain multiple actions (e.g., if + logger, write + return). Reading flow is disrupted by inconsistent indentation and one-line imports. Despite meaningful names and a straightforward high-level flow, the overall presentation significantly reduces clarity.

Run 3

The code suffers from severe readability issues. Multiple statements and imports are crammed onto single lines, violating one-action-per-line. Class and method declarations share lines with javadoc comments, obscuring structure. Deeply nested conditional blocks in handleRequestInternal combine logging with transport logic, making the flow difficult to follow. The overall organization feels tangled; reading flow is disorganized and unnatural. While naming is generally clear, the compressed formatting, excessive nesting, and mixed responsibilities make the code very hard to parse. It reads like minified or auto-collapsed source rather than human-maintained code.

Run 1

Code Structure: Responsibilities are logically separated into request handling, frame writing, and callback validation, but compressed formatting obscures method boundaries. Nesting: Generally moderate, with session-state branches containing additional logging checks; inline braces make nesting harder to follow. Clarity of intent: Descriptive method names, explicit session-state checks, and useful comments communicate purpose well. Code length: The implementation is reasonably concise, although long signatures and compressed statements reduce scanability; commented-out code adds minor clutter. Action granularity: Multiple imports, declarations, conditionals, and actions share lines, undermining the one-action-per-line principle. Reading flow: The high-level progression is natural, but inconsistent indentation, crowded braces, and comments attached to declarations repeatedly interrupt reading.

Run 2

Code Structure: Responsibilities are logically separated into request handling, frame writing, and callback validation methods. Nesting: Session-state branches contain shallow logging checks; nesting is manageable, though compressed formatting obscures boundaries. Clarity of intent: Descriptive method and variable names, framework types, and comments explain the purpose, but the commented-out protocol code adds noise. Code length: The implementation is reasonably concise without substantial duplication, although long signatures and expressions require effort to scan. Action granularity: Multiple imports, declarations, conditionals, and statements share lines, weakening visual separation. Reading flow: The overall method sequence is natural, but inconsistent indentation, inline braces, attached documentation, and irregular whitespace repeatedly interrupt reading.

Run 3

Code Structure: Methods separate request handling, frame writing, and callback validation logically, but cramped formatting obscures these boundaries. Nesting: Mostly shallow, with session-state branches containing nested logging checks; manageable but harder to scan due to inline braces. Clarity of intent: Descriptive method names, session predicates, and comments make the transport behavior understandable. Code length: Reasonably concise without major duplication, although long signatures and expressions reduce readability. Action granularity: Multiple imports, declarations, statements, and closing braces share lines, making individual actions difficult to distinguish. Reading flow: The session-state decision sequence is natural, but inconsistent indentation, irregular spacing, inline annotations and comments, and commented-out code interrupt it. Overall, the underlying design is readable, while presentation substantially weakens scanability.