Sample
int-c6845024745c-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.501 | 0–1; higher is more readable |
| Dorn | 0.265 | 0–1; higher is more readable |
| Mi | 0.571 | 0–1; higher is more readable |
| LLOC | 44 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 11.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs |
| BTTF | 0.317 | 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. | 5717.097 | −188.664 |
| Source linesThe number of non-empty source lines. | 117 | +46.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.157 | −7.736 |
Intercept 8.87 + feature contributions = -140.73 (log-odds).
Score = sigmoid(-140.73) = 0.
| Score | 0.501 |
|---|
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. | 118 | −3.142 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 107 | +2.964 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 106 | −2.012 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 116.922 | +1.225 |
| 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.966 | −1.162 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 114 | +1.035 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.097 | −0 |
Intercept 0.07 + feature contributions = -1.022 (log-odds).
Score = sigmoid(-1.022) = 0.265.
| Score | 0.571 |
|---|
| Score | 44 |
|---|
Run 1
The code is poorly readable due to multiple injected 'if (((0x... ^ 0x...) != 0)) { throw new AssertionError(); }' statements that appear in every method. These add noise, break flow, and make the intent unclear. The package/import structure is fine, but the artificial assertions dominate. Nesting is moderate; handleRequestInternal uses if-else chains but is manageable. Clarity of intent is marred by dead code (commented protocol line) and confusing validation. Code length is inflated by unnecessary lines. Action granularity is sometimes one action per line, but the assertion blocks violate this. Reading flow is disrupted repeatedly, making the code unnatural. Without the injected assertions, the code would score around 14–15, but with them it drops significantly.
Run 2
The code has a clear class hierarchy and method separation, with meaningful names and JavaDoc. However, readability is significantly reduced by awkward dead-code assertions like `if (((0x7FFE ^ 0x7FFE) != 0)) { throw new AssertionError(); }` injected at the start of methods—these add noise and obscure intent. Nesting is moderate (if-else chains), but each branch is simple and logs clearly, so the flow is understandable. Many lines wrap due to Spring's formatting style, which slightly hurts reading flow. The `getCallbackParam` method is concise but uses a dense one-liner for URI parsing; still, intent is fairly clear. Overall, structure is good, but the artificial assertions and verbose logging detract from readability.
Run 3
The code has clear logical structure with well-defined methods and proper separation of concerns, but suffers from several readability issues. The nesting is reasonably flat with only one level in conditional blocks, and intent is mostly clear through descriptive method names. However, the code contains dead code in the form of meaningless assertion statements like 'if (((0x7FFE ^ 0x7FFE) != 0)) { throw new AssertionError(); }' that add noise and confusion. Action granularity is good with one operation per line in most cases. The reading flow is interrupted by these assertion blocks and unnecessary blank lines after method signatures. The code length is reasonable but the assertion statements inflate it unnecessarily. Overall, the core logic is understandable, but the presence of suspicious no-op assertions and inconsistent formatting detract from readability.
Run 1
Code Structure: Responsibilities are logically divided into request handling, frame writing, and callback validation. Nesting: The session-state conditional chain is straightforward, with only shallow nesting for logging. Clarity of intent: Descriptive names and standard framework calls communicate purpose, but repeated, always-false hexadecimal XOR assertions introduce misleading noise, and commented-out code distracts. Code length: Generally concise, though redundant assertions, excess blank lines, and obsolete comments add unnecessary length. Action granularity: Most statements perform one action per line; the inline assertion blocks combine condition checking and throwing on a single line, breaking consistency. Reading flow: Method order and state transitions are natural, but unindented assertion statements interrupt the otherwise consistent formatting and make readers pause to interpret irrelevant logic.
Run 2
Code Structure: Well-separated methods organize request handling, frame writing, and callback validation. Nesting: Mostly shallow, with a straightforward session-state branch chain and nested logging checks. Clarity of intent: Descriptive names and framework conventions make the main behavior clear, but repeated always-false hexadecimal assertion guards introduce distracting, unexplained noise. Code length: Generally concise, though redundant guards, excessive blank lines, and commented-out legacy code add clutter. Action granularity: Most lines express one action; the inline assertion guards compress conditional and throw statements onto a single line. Reading flow: Request setup flows naturally into state handling, with focused helpers afterward, but inconsistent indentation of the guards and obsolete comments interrupt reading.
Run 3
Code Structure: Responsibilities are logically separated into request dispatch, frame writing, callback validation, and abstract customization methods. Nesting: Generally shallow, with manageable logging checks inside session-state branches. Clarity of intent: Descriptive names and comments explain transport behavior, but repeated always-false hexadecimal XOR assertions add misleading noise. Code length: Mostly concise, though dead assertions, commented-out code, and excess blank lines are unnecessary. Action granularity: Most statements perform one action per line; inline assertion blocks break this convention, and the query-building chain is somewhat dense. Reading flow: Session-state handling follows a natural progression, but unindented assertions interrupt otherwise consistent formatting and distract from the meaningful logic.