Sample
int-f82bf32e5dce-I08
Select one of ten high-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.498 | 0–1; higher is more readable |
| Dorn | 0.276 | 0–1; higher is more readable |
| Mi | 0.57 | 0–1; higher is more readable |
| LLOC | 41 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 13 | 0–20; mean of three runs |
| GPT-6.1 Sol | 14.67 | 0–20; mean of three runs |
| BTTF | 0.244 | 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. | 5277.233 | −174.149 |
| Source linesThe number of non-empty source lines. | 118 | +47.2 |
| 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.097 | −7.646 |
Intercept 8.87 + feature contributions = -125.725 (log-odds).
Score = sigmoid(-125.725) = 0.
| Score | 0.498 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 119 | −3.177 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 108 | +2.998 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 107 | −2.034 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 117.922 | +1.238 |
| 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. | 113.908 | −1.159 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 113.992 | +1.035 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.09 | +0.065 |
Intercept 0.07 + feature contributions = -0.964 (log-odds).
Score = sigmoid(-0.964) = 0.276.
| Score | 0.57 |
|---|
| Score | 41 |
|---|
Run 1
The code is generally well-structured with clear separation of concerns and good use of helper methods. However, there are significant readability issues. The handleRequestInternal method has multiple nested if-else branches with repeated logger blocks, increasing nesting depth. The writeFrame method contains a strange, unrelated block computing travelDistance that appears to be dead code or an accidental insertion, which is extremely confusing and hurts clarity of intent. The method also mixes concerns: it formats a frame, writes it, and handles exceptions in one place. Naming is mostly clear, and the getCallbackParam method reads naturally. Logging blocks are verbose and repetitive, adding unnecessary length. The class-level Javadoc is helpful, but the overall jarring dead code block and repeated conditionals reduce readability. The code could be improved by extracting log-and-handle logic, removing dead code, and simplifying conditional flow.
Run 2
The code is generally well-structured and readable, with clear method names and logical separation of concerns. It follows Spring conventions and has helpful comments. However, there's a significant issue: the writeFrame method contains dead/unrelated code (a block calculating travelDistance) that breaks the reading flow and creates confusion. This appears to be leftover debugging code or an accidental paste. Additionally, the nested if-else blocks with logger checks add some noise, though they're for valid logging purposes. The handleRequestInternal method has moderate nesting but remains understandable. The getCallbackParam method is flat and clear. Overall, the code reads naturally except for that extraneous block in writeFrame, which significantly impacts clarity. Score would be higher without that anomaly.
Run 3
The code has a clear class structure with descriptive method names and decent documentation, but several issues hurt readability. A stray code block (startingPosition, endingPosition, travelDistance) is accidentally embedded inside writeFrame, creating dead code that disrupts reading flow. Nesting is generally flat which is good, but the chain of else-if branches in handleRequestInternal makes the flow somewhat hard to scan at a glance. Clarity of intent is mostly good—method names like handleInitialRequest and writeFrame are descriptive—but the commented-out code and verbose logging conditions add noise. Code length is reasonable, though the repeated logger.isDebugEnabled() checks and string concatenation feel unnecessarily long. Action granularity is mostly one action per line, which helps. Overall, the accidental dead code block and minor verbosity pull the readability score down significantly from what would otherwise be a solid 15-16.
Run 1
Code Structure: Responsibilities are separated into request handling, frame writing, and callback parsing, but an unrelated travel-distance block disrupts writeFrame. Nesting: Generally shallow, with modest nested logging checks; the extraneous scoped block adds unnecessary nesting. Clarity of intent: Descriptive method names and session-state checks make transport behavior clear, while unused distance calculations and commented-out code introduce confusion. Code length: Mostly concise, though repetitive logging guards and irrelevant statements add clutter. Action granularity: Statements generally perform one action per line; callback parsing contains a somewhat dense chained expression. Reading flow: Request processing follows a logical sequence, but inconsistent indentation in the inserted block and excessive blank lines interrupt otherwise consistent formatting.
Run 2
Code Structure: Methods logically separate request dispatch, frame writing, and callback validation, but an unrelated distance-calculation block disrupts writeFrame. Nesting: Mostly shallow; session-state branches contain only one additional logging conditional, while the stray block adds unnecessary nesting. Clarity of intent: Descriptive method and variable names clarify transport behavior, but unused distance calculations and commented-out protocol code create confusion. Code length: Generally concise, though dead calculations, repeated logging guards, and obsolete comments add noise. Action granularity: Most lines perform one clear action; chained query parsing is slightly dense. Reading flow: Request handling follows a natural state-based sequence, but inconsistent indentation in the injected block abruptly breaks the flow.
Run 3
Code Structure: Responsibilities are logically separated into request handling, frame writing, and callback validation, but an unrelated travel-distance block disrupts writeFrame. Nesting: Generally shallow; session-state branches contain only modest additional logging checks. Clarity of intent: Descriptive method names and explicit session-state checks communicate purpose well, while unused travel-distance calculations and commented-out protocol code introduce ambiguity. Code length: Mostly concise, though the irrelevant block, obsolete comments, and repeated logging guards add clutter. Action granularity: Statements generally perform one action per line; callback parsing uses a somewhat dense fluent chain. Reading flow: Request setup, state dispatch, and helper methods follow a natural sequence, but the stray block's inconsistent indentation and unnecessary scope sharply interrupt that flow.