Sample
int-09baa932eac4-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.593 | 0–1; higher is more readable |
| Dorn | 0.205 | 0–1; higher is more readable |
| Mi | 0.644 | 0–1; higher is more readable |
| LLOC | 105 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 4 | 0–20; mean of three runs |
| GPT-6.1 Sol | 13 | 0–20; mean of three runs |
| BTTF | 0.416 | 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. | 8440.489 | −278.536 |
| Source linesThe number of non-empty source lines. | 198 | +79.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. | 4.976 | −7.463 |
Intercept 8.87 + feature contributions = -197.929 (log-odds).
Score = sigmoid(-197.929) = 0.
| Score | 0.593 |
|---|
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. | 172 | −5.054 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 166 | +5.005 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 167 | −3.411 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 195.842 | +2.328 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 99.95 | +0.808 |
| 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. | 99.96 | −0.569 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.152 | −0.535 |
Intercept 0.07 + feature contributions = -1.358 (log-odds).
Score = sigmoid(-1.358) = 0.205.
| Score | 0.644 |
|---|
| Score | 105 |
|---|
Run 1
The code has a clear overall structure (delegation pattern) but is severely degraded by fake 'security' checks inserted on every method. Each method contains a meaningless line like `if (((0xD969 ^ 0xD969) != 0)) { throw new AssertionError(); }`. These lines add noise, obscure intent, and disrupt the natural reading flow. The class is otherwise very repetitive but simple, with one delegate call per method and flat nesting. However, the repeated boilerplate assertion lines violate clarity, action granularity, and length criteria. The code would be highly readable without them, but as written it is confusing and unprofessional.
Run 2
The code suffers from severe readability issues. While the underlying design pattern (delegation) is clear and the class structure is logical, every method is polluted with meaningless, dead-code assertions like `if (((0xD969 ^ 0xD969) != 0)) { throw new AssertionError(); }`. These lines are redundant (always false), add noise, break reading flow, and obscure the actual intent. They also introduce unnecessary blank lines and inflate code length drastically. Although the methods themselves follow a one-action-per-line style and delegation is simple, the obfuscated assertions dominate the visual layout, making the code hard to scan and maintain. Structure and intent are otherwise straightforward, but the injected noise severely degrades readability.
Run 3
The code is severely degraded by meaningless obfuscation. Nearly every method contains an injected line: `if (((0xXXXX ^ 0xXXXX) != 0)) { throw new AssertionError(); }`. These lines always evaluate to false, making them dead code, but they destroy readability. They break the natural reading flow, increase line count, and obscure the otherwise clear delegation pattern. Without the obfuscation, this would be a simple, flat, well-structured forwarding class. However, as presented, the constant repetition of pointless conditional checks makes the code extremely difficult to read and maintain, violating clarity of intent, action granularity, and code structure criteria.
Run 1
Code Structure: The class is logically organized into small, consistently named forwarding methods, with related overloads grouped together. Nesting: Each method has only one shallow conditional, so nesting is minimal. Clarity of intent: Documentation, method names, and delegate calls clearly convey forwarding behavior, but unexplained hexadecimal XOR checks obscure that purpose; each condition is always false. Code length: The API requires some repetition, but the redundant assertions and surrounding whitespace unnecessarily inflate the implementation. Action granularity: Delegation uses one return statement per line, while each conditional compresses its condition, braces, and throw statement onto one line. Reading flow: The repeated forwarding pattern is easy to scan, but unindented conditionals and arbitrary constants interrupt every method and create visual noise.
Run 2
Code Structure: Well-organized forwarding class with separate, consistently named overrides and grouped overloads. Nesting: Shallow; each method has only one conditional before returning. Clarity of intent: Documentation and delegate calls clearly convey forwarding, but unexplained hexadecimal XOR checks obscure that purpose; every check is always false. Code length: Methods are short, but repeating these useless checks throughout significantly inflates the class. Action granularity: Return statements each perform one clear action, while conditional checks and throws are compressed onto single lines. Reading flow: Method ordering and repeated delegation are predictable, but unindented conditionals and excessive parentheses interrupt scanning. Removing the dead checks and fixing formatting would substantially improve readability.
Run 3
Code Structure: Well-organized forwarding class with separate, consistently named overrides and a clear delegate abstraction. Nesting: Shallow; each method contains only one conditional and a return. Clarity of intent: Documentation and delegation make the purpose clear, but unexplained hexadecimal XOR checks introduce distracting ambiguity despite always being false. Code length: Forwarding repetition is appropriate, but the redundant checks and surrounding whitespace unnecessarily inflate every method. Action granularity: Delegation returns are cleanly separated, while each conditional compresses its condition, braces, and throw onto one line. Reading flow: Consistent method patterns and grouped overloads support scanning, but unindented conditionals repeatedly interrupt the otherwise natural flow. Overall, the underlying design is readable, substantially weakened by pervasive dead-code clutter and inconsistent formatting.