Sample
int-aabcd3612d29-I10
Remove about 40% of line-break groups while retaining structure
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.336 | 0–1; higher is more readable |
| Dorn | 0.008 | 0–1; higher is more readable |
| Mi | 0 | 0–1; higher is more readable |
| LLOC | 36 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 9 | 0–20; mean of three runs |
| GPT-6.1 Sol | 11 | 0–20; mean of three runs |
| BTTF | 0.179 | 0–1; higher is more readable |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (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.
| Score | 0.336 |
|---|
Feature contributions
| Feature | Value | Contribution (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.
| Score | 0 |
|---|
| Score | 36 |
|---|
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.