Sample
int-176962dfc2c5-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.539 | 0–1; higher is more readable |
| Dorn | 0.176 | 0–1; higher is more readable |
| Mi | 0.254 | 0–1; higher is more readable |
| LLOC | 75 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 9 | 0–20; mean of three runs |
| GPT-6.1 Sol | 13 | 0–20; mean of three runs |
| BTTF | 0.403 | 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. | 8002.432 | −264.08 |
| Source linesThe number of non-empty source lines. | 183 | +73.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.046 | −7.569 |
Intercept 8.87 + feature contributions = -189.579 (log-odds).
Score = sigmoid(-189.579) = 0.
| Score | 0.539 |
|---|
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. | 184 | −5.479 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 162 | +4.866 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 162 | −3.297 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 182.901 | +2.147 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 98.918 | +0.792 |
| 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.962 | −0.569 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.105 | −0.076 |
Intercept 0.07 + feature contributions = -1.545 (log-odds).
Score = sigmoid(-1.545) = 0.176.
| Score | 0.254 |
|---|
| Score | 75 |
|---|
Run 1
The code has a clear class structure and purpose, with well-separated methods and good naming. However, readability is severely degraded by the dozens of inserted fake assertion lines like `if (((0xCA7E ^ 0xCA7E) != 0)) { throw new AssertionError(); }` before every method body. These add no logic, break the natural reading flow, and obscure the actual intent of each method. While the underlying logic is concise and delegation is straightforward, the repetitive dead code makes every method unnecessarily long and confusing. Nesting is mostly flat, and action granularity is reasonable, but the cluttered method bodies dominate the experience. Overall, the code is structurally sound but practically unreadable due to the extraneous assertions.
Run 2
The code has a clear overall structure: wrapping methods first, then delegating methods, which aids logical organization. However, the presence of dead code (`if (((0xCA7E ^ 0xCA7E) != 0)) { throw new AssertionError(); }`) in every method severely hurts readability by adding noise and confusing intent. Nesting is mostly flat and action granularity is reasonable. Intent is somewhat clear based on method names and comments, but the obfuscated assertions obscure it. The class is concise overall, though the repeated dead-code blocks make it unnecessarily long. Reading flow is natural due to consistent method grouping, but each method starts with an unrelated, confusing statement.
Run 3
The code is structurally clear with logical method grouping and good delegation patterns, but it is severely undermined by the presence of obfuscated dead-code assertions (e.g., 'if (((0xCA7E ^ 0xCA7E) != 0)) { throw new AssertionError(); }') inserted at the start of every method. These lines add noise, disrupt reading flow, and obscure intent, making the code appear intentionally obfuscated. Nesting is otherwise flat, and action granularity is mostly one action per line, but the repeated meaningless checks break clarity and make the code unnecessarily long. The core logic (task wrapping and delegation) is readable, but the overall impression is unreadable due to the injected clutter.
Run 1
Code Structure: Methods are logically grouped into task-wrapping operations and direct delegation, with reusable helpers. Nesting: Generally shallow; the lambda's try/catch is manageable, but unnecessary conditionals add clutter. Clarity of intent: Descriptive names and Javadoc explain the executor wrapper well, while repeated hexadecimal XOR checks obscure intent despite always evaluating to false. Code length: Most delegation methods are concise, but redundant assertion guards unnecessarily expand every method. Action granularity: Meaningful operations generally occupy separate lines; compact guard statements combine conditional control and throwing on one poorly indented line. Reading flow: Consistent method patterns and section comments support scanning, but the unindented, meaningless guards repeatedly interrupt the natural flow.
Run 2
Code Structure: Methods are logically grouped into task wrapping and direct delegation, with reusable helpers. Nesting: Mostly flat; the lambda's try/catch and collection loop add only modest nesting. Clarity of intent: Descriptive names and documentation explain the executor wrapper well, but repeated hexadecimal XOR checks obscure otherwise simple methods despite always evaluating to false. Code length: Most delegation methods are appropriately concise, but unnecessary assertion checks and surrounding blank lines inflate the implementation. Action granularity: Meaningful operations generally occupy separate lines, while each injected check compresses a condition, block, and throw onto one line. Reading flow: Consistent method patterns and section comments support scanning, but unindented dead-code checks repeatedly interrupt the flow and undermine formatting consistency.
Run 3
Code Structure: Methods are logically grouped into task wrapping, submission, and lifecycle delegation, with reusable helpers. Nesting: Mostly shallow; the Runnable adapter adds a manageable lambda and try/catch. Clarity of intent: Descriptive names and documentation clearly explain the wrapper's purpose, but repeated always-false hexadecimal XOR checks introduce confusing, purposeless noise. Code length: Most methods are concise, although redundant assertion guards unnecessarily inflate the class. Action granularity: Functional statements generally perform one action per line, while the guards compress conditions and throws onto single lines. Reading flow: Consistent delegation patterns and section comments support natural reading, but unindented guards repeatedly interrupt that flow and undermine formatting consistency.