Sample
int-0c97b0860be8-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.572 | 0–1; higher is more readable |
| Dorn | 0.195 | 0–1; higher is more readable |
| Mi | 0.755 | 0–1; higher is more readable |
| LLOC | 68 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 3.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 12 | 0–20; mean of three runs |
| BTTF | 0.461 | 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. | 5602.756 | −184.891 |
| Source linesThe number of non-empty source lines. | 158 | +63.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.199 | −7.798 |
Intercept 8.87 + feature contributions = -120.619 (log-odds).
Score = sigmoid(-120.619) = 0.
| Score | 0.572 |
|---|
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. | 159 | −4.593 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 151 | +4.486 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 151 | −3.044 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 157.788 | +1.796 |
| 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. | 116.95 | −1.288 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 116.962 | +1.083 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.089 | +0.073 |
Intercept 0.07 + feature contributions = -1.419 (log-odds).
Score = sigmoid(-1.419) = 0.195.
| Score | 0.755 |
|---|
| Score | 68 |
|---|
Run 1
The code is largely unreadable due to the pervasive presence of meaningless, obfuscated no-op checks like `if (((0x250A ^ 0x250A) != 0)) { throw new AssertionError(); }` before every method body. This destroys clarity, breaks natural reading flow, and makes every action multiple lines. The Xor of a number with itself is always zero, so these checks are dead code that adds noise. While the overall class structure (fields, grouped methods) and concise naming are reasonable, they are completely overshadowed by the obfuscation. Nesting is shallow, but code length is unnecessarily inflated. Intent is clear only if ignoring the injected nonsense lines; with them, the purpose appears intentionally sabotaged. Fails key readability criteria.
Run 2
The code is severely degraded by the injection of meaningless assertion statements like 'if (((0x250A ^ 0x250A) != 0)) { throw new AssertionError(); }' in nearly every method. These lines break the reading flow and clutter every action, making the logic difficult to follow. While the class structure and method names are logical, the excessive repetition of no-op assertions plus the deep multi-line exception-throwing statements creates unnecessary noise. The original purpose (a mock implementation) is clear, but the added artifacts make the code nearly unreadable. Overall, it is very hard to scan or maintain due to the pervasive tautological conditions and poor action granularity.
Run 3
The code is heavily polluted with meaningless, obfuscated assertions like 'if (((0x250A ^ 0x250A) != 0)) { throw new AssertionError(); }' inserted at the start of nearly every method. These lines add no functional value, destroy readability, and make the intent of each method difficult to discern immediately. Structure is logically grouped by interface (WebSocketContainer vs ServerContainer), but the constant noise breaks the natural reading flow. Nesting is minimal, and method lengths are short, but the sheer repetition of pointless boilerplate makes the code unnecessarily long. Action granularity is fine when the noise is ignored, but the assertions are extra actions per method that obscure the real return or throw statements. Clarity of intent is severely harmed because the reader must mentally filter out the irrelevant assertions before understanding that this is a mock implementation throwing UnsupportedOperationException for unsupported operations. Overall, the code is technically simple but practically unreadable due to deliberate obfuscation.
Run 1
Code Structure: Fields and methods are logically organized into interface-specific sections. Nesting: Methods remain shallow, with only a single conditional level. Clarity of intent: Descriptive names, documentation, and explicit unsupported-operation messages clarify the mock's purpose, but repeated hexadecimal XOR checks introduce misleading noise despite always being false. Code length: Individual methods are short, yet redundant checks and excessive blank lines unnecessarily expand the class. Action granularity: Most meaningful statements occupy separate lines, but each injected conditional compresses its check and throw into one line. Reading flow: Consistent method patterns aid scanning, while unindented conditionals and irregular spacing repeatedly interrupt the otherwise natural flow.
Run 2
Code Structure: Fields and methods are logically organized, with interface sections clearly labeled. Nesting: Methods remain shallow, although every method contains an unnecessary conditional. Clarity of intent: Descriptive names and explicit unsupported-operation messages clarify the mock's purpose, but hexadecimal XOR checks that always evaluate to false introduce confusing noise. Code length: Individual methods are short, yet repeated dead checks and excessive blank lines unnecessarily expand the class. Action granularity: Meaningful operations generally occupy separate lines, but each injected check compresses a conditional and throw onto one line. Reading flow: Consistent accessor patterns and method grouping support scanning, while unindented checks repeatedly interrupt the otherwise natural flow.
Run 3
Code Structure: Fields and methods are logically organized, with interface sections clearly labeled. Nesting: Methods remain shallow, although every method contains an unnecessary conditional. Clarity of intent: Descriptive names, documentation, and explicit unsupported-operation messages clarify the mock's purpose, but hexadecimal XOR checks obscure otherwise straightforward behavior; each check is always false. Code length: Interface implementation requires some repetition, but redundant checks and excess blank lines unnecessarily expand the code. Action granularity: Core operations occupy individual lines, while conditional checks and throws are compressed onto single lines. Reading flow: Consistent method patterns help navigation, but unindented checks interrupt visual hierarchy and force readers to repeatedly process irrelevant logic.