Sample
int-154ff9276d34-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.464 | 0–1; higher is more readable |
| Dorn | 0.15 | 0–1; higher is more readable |
| Mi | 0.546 | 0–1; higher is more readable |
| LLOC | 70 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 9.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 13.67 | 0–20; mean of three runs |
| BTTF | 0.38 | 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. | 6319.805 | −208.554 |
| Source linesThe number of non-empty source lines. | 149 | +59.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.125 | −7.688 |
Intercept 8.87 + feature contributions = -147.772 (log-odds).
Score = sigmoid(-147.772) = 0.
| Score | 0.464 |
|---|
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. | 150 | −4.275 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 136 | +3.967 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 136 | −2.7 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 148.792 | +1.67 |
| 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. | 123.94 | −1.584 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 123.993 | +1.196 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.105 | −0.077 |
Intercept 0.07 + feature contributions = -1.733 (log-odds).
Score = sigmoid(-1.733) = 0.15.
| Score | 0.546 |
|---|
| Score | 70 |
|---|
Run 1
The code is generally structured logically but contains noise from dead code: every method includes a meaningless `if (((0x5951 ^ 0x5951) != 0)) { throw new AssertionError(); }` check. This adds clutter and hurts readability. Nesting is mostly low; the main convert method has one loop and straightforward conditionals. Intent is clear from method names and comments. However, the 'shortcut' logic and 'copyRequired' tracking make the flow harder to follow than necessary. Action granularity is good—one operation per line. Reading flow is disrupted by the assertion lines and slightly redundant helper methods. Without the dead code, this would score higher.
Run 2
The code has a clear overall structure with logical method separation, but readability is severely degraded by multiple issues. Every method contains an obfuscated no-op assertion line like 'if (((0x5951 ^ 0x5951) != 0)) { throw new AssertionError(); }' which adds noise and breaks reading flow. Indentation is inconsistent in several places. The convert method is too long and performs multiple responsibilities: type checking, entry conversion, copy detection, and map construction. While helper methods like canConvertKey/canConvertValue improve action granularity, the main convert method still mixes several actions per block. The MapEntry inner class is a reasonable abstraction, but the overall effect is muddied by the injected assertion lines. Without the artifact code, this would score higher, but as presented, it significantly impairs clarity of intent and code length.
Run 3
The code has reasonable structure and naming, but readability is severely degraded by several factors. Each method is polluted with meaningless `if (((0x... ^ 0x...) != 0)) { throw new AssertionError(); }` statements that are always false, adding noise and disrupting flow. Indentation is inconsistent in these lines. The core `convert` method is long and handles multiple responsibilities: null checks, shortcut logic, type descriptor extraction, conversion loop, and map creation. While the creation of the `MapEntry` helper improves granularity somewhat, the main method still performs many actions. The reading flow is interrupted by the artificial assertions and multi-line conditional expressions. Removing these artifacts, improving indentation, and extracting a helper for target entry conversion would significantly improve clarity. The documentation comment is helpful and concise. Overall, the code is understandable for a Spring developer but falls short of high readability due to these issues.
Run 1
Code Structure: Well organized into converter methods, focused helpers, and a small entry class. Nesting: Shallow loops and conditionals, with early returns keeping complexity manageable. Clarity of intent: Documentation and descriptive names clearly explain map conversion, but repeated always-false hexadecimal XOR checks introduce confusing, purposeless noise. Code length: Mostly justified by conversion and copy-avoidance logic, although dead assertions and excessive blank lines add unnecessary bulk. Action granularity: Most lines perform one action; inline assertion conditionals compress control flow and throwing onto a single line. Reading flow: The main conversion follows a natural sequence, but unindented dead checks interrupt every method and undermine otherwise consistent formatting.
Run 2
Code Structure: Logical separation of conversion, compatibility checks, and entry storage makes the class organized. Nesting: Shallow loops and conditionals, plus early returns, keep complexity manageable. Clarity of intent: Descriptive names and documentation explain map conversion well, but repeated always-false hexadecimal XOR assertions introduce confusing, purposeless noise. Code length: Most conversion logic is reasonably concise; redundant assertions and some helper boilerplate unnecessarily increase length. Action granularity: Meaningful operations generally occupy separate lines, although injected assertions combine conditions and throws on single lines. Reading flow: The main conversion sequence is natural, progressing from validation through element conversion to map construction. However, unindented assertions interrupt every method and undermine otherwise consistent formatting.
Run 3
Code Structure: The converter is logically organized into public operations, focused helpers, and a small entry class. Nesting: Early returns keep nesting shallow; the conversion loop contains only one conditional. Clarity of intent: Descriptive names and documentation explain map conversion, but repeated always-false hexadecimal XOR checks introduce confusing, irrelevant noise. Code length: The functional implementation is reasonably concise, although dead checks and repeated helper patterns add unnecessary length. Action granularity: Most lines perform one clear action, but the inline conditional-and-throw statements compress multiple constructs onto single lines. Reading flow: Conversion proceeds naturally from validation through entry conversion to map construction; however, unindented dead checks interrupt every method and undermine otherwise consistent formatting.