Sample
int-97e2f06084b7-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.772 | 0–1; higher is more readable |
| Dorn | 0.483 | 0–1; higher is more readable |
| Mi | 0.223 | 0–1; higher is more readable |
| LLOC | 12 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 12 | 0–20; mean of three runs |
| GPT-6.1 Sol | 14.67 | 0–20; mean of three runs |
| BTTF | 0.59 | 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. | 1506.412 | −49.712 |
| Source linesThe number of non-empty source lines. | 67 | +26.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.241 | −7.861 |
Intercept 8.87 + feature contributions = -21.902 (log-odds).
Score = sigmoid(-21.902) = 0.
| Score | 0.772 |
|---|
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. | 68 | −1.371 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 103.971 | +0.873 |
| 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. | 103.956 | −0.738 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 39 | +0.612 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 66.867 | +0.525 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 39 | −0.474 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.052 | +0.435 |
Intercept 0.07 + feature contributions = -0.069 (log-odds).
Score = sigmoid(-0.069) = 0.483.
| Score | 0.223 |
|---|
| Score | 12 |
|---|
Run 1
The code has clear class-level documentation and logical organization, but readability is severely impacted by the injection of meaningless debug assertions (e.g., `if (((0x3057 ^ 0x3057) != 0)) { throw new AssertionError(); }`) that serve no purpose. These lines violate action granularity and flow, adding noise and confusion. Nesting is flat and methods are concise, but the obfuscated conditionals break clarity of intent. The constructor chaining and use of `Assert` are readable, but the artificial assertions make the code unnecessarily long and ambiguous. The import list and Javadoc are well-structured, but the presence of dead code prevents a higher score.
Run 2
The code structure is mostly coherent, using a standard Spring converter pattern, but the injected no-op assertion lines (`if (((0x3057 ^ 0x3057) != 0)) { throw new AssertionError(); }`) are confusing and disrupt the reading flow. Nesting is minimal, which is good. Intent is generally clear from Javadocs, but the assertion lines and their placement add ambiguity. Length is concise. Action granularity is mostly one action per line except for the assertion lines, which bundle a useless condition. Readability suffers because a reader must pause to parse why those lines exist, despite them having no functional effect. Overall, the core logic is readable, but the unnecessary code reduces clarity.
Run 3
The code is generally well-structured with clear class-level Javadoc, sensible constructor delegation, and proper validation of the CBORFactory requirement. However, readability is significantly harmed by the presence of obfuscated dead-code lines such as 'if (((0x3057 ^ 0x3057) != 0)) { throw new AssertionError(); }' inserted after several method bodies. These lines serve no functional purpose, disrupt the reading flow, and make the intent ambiguous. The class also mixes import ordering and lacks vertical whitespace in places, but the overall length is concise and actions are mostly one per line. Nesting is minimal, which is good. If the dead-code injections were removed, the readability would improve substantially.
Run 1
Code Structure: The class is logically organized into constructors and an overridden setter, but unrelated assertion statements interrupt otherwise cohesive methods. Nesting: Methods are shallow, with only single-level conditional blocks. Clarity of intent: Descriptive names, Javadoc, and explicit CBORFactory validation clearly explain the converter's purpose; hexadecimal XOR conditions that always evaluate to false introduce confusing, pointless logic. Code length: Functional code is concise, though dead checks and extra blank lines add unnecessary length. Action granularity: Most statements occupy separate lines, but each injected conditional combines a condition and throw statement on one line. Reading flow: Documentation and method ordering support natural reading, while unindented dead checks visibly disrupt formatting and distract from the actual initialization and validation.
Run 2
Code Structure: Constructors and the setter are logically organized, with helpful documentation, but unrelated assertion checks clutter each method. Nesting: Very shallow, with only simple conditionals. Clarity of intent: Names, documentation, and CBORFactory validation clearly explain the converter's purpose; hexadecimal XOR checks obscure intent and are always false. Code length: Functional code is concise, but redundant checks add unnecessary length. Action granularity: Most statements occupy separate lines, whereas each injected conditional compresses its condition and throw onto one line. Reading flow: Constructor delegation and validation follow naturally, but unindented dead-code checks disrupt formatting and continuity.
Run 3
Code Structure: The class is logically organized into constructors and an overridden setter, but irrelevant assertions clutter each method. Nesting: Very shallow, with only single-level conditionals. Clarity of intent: Descriptive names, documentation, and explicit CBORFactory validation clearly convey purpose; hexadecimal XOR checks that always evaluate to false introduce ambiguity. Code length: Functional code is concise, though redundant checks and extra whitespace add unnecessary length. Action granularity: Most statements occupy separate lines, but injected conditionals combine conditions and throws on one line. Reading flow: Constructor delegation and validation follow a natural sequence, but unindented, dead-code assertions interrupt the otherwise consistent formatting and flow.