Sample
int-23b5023f7895-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.392 | 0–1; higher is more readable |
| Dorn | 0.157 | 0–1; higher is more readable |
| Mi | 0.048 | 0–1; higher is more readable |
| LLOC | 57 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 4.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 13.67 | 0–20; mean of three runs |
| BTTF | 0.347 | 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. | 6411.595 | −211.583 |
| Source linesThe number of non-empty source lines. | 121 | +48.4 |
| 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.879 | −7.318 |
Intercept 8.87 + feature contributions = -161.63 (log-odds).
Score = sigmoid(-161.63) = 0.
| Score | 0.392 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 117 | +3.31 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 122 | −3.283 |
| 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. | 142.959 | −2.39 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 117 | −2.264 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 142.984 | +1.503 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 120.875 | +1.28 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.087 | +0.098 |
Intercept 0.07 + feature contributions = -1.677 (log-odds).
Score = sigmoid(-1.677) = 0.157.
| Score | 0.048 |
|---|
| Score | 57 |
|---|
Run 1
The code has severe readability issues. The most glaring problem is the injection of meaningless assertion statements (e.g., 'if (((0xFAFB ^ 0xFAFB) != 0)) { throw new AssertionError(); }') at the start of nearly every method. These lines are always false, serve no discernible purpose, and disrupt the reading flow and visual structure of the code. Beyond this, while the overall class structure is logical and methods are generally concise, the code lacks clarity in intent due to these extraneous lines. The 'endOffsetMetadata' method uses an if-else chain instead of a clearer switch or ternary, but this is minor compared to the assertion clutter. Action granularity is otherwise reasonable, with clear, single-purpose method calls and error handling. However, the pervasive, nonsensical assertions dominate the evaluation, severely impacting readability, nesting perception, and overall score.
Run 2
The code contains severe readability issues. Obscure assertion statements like `if (((0xFAFB ^ 0xFAFB) != 0)) { throw new AssertionError(); }` appear randomly at the start of nearly every method. These are nonsensical to a human reader, break natural reading flow, and add visual noise without conveying any intent. While the overall class structure is logical and method names are clear, the repeated meaningless assertions dominate the code and destroy clarity. Some methods have reasonable one-action-per-line flow and limited nesting, but the artificial clutter outweighs these strengths. Additionally, the long method chaining in offset lookup methods slightly reduces readability, though not critically. Overall, the code structure is understandable, but the pervasive AssertionError noise and poor formatting make it highly unreadable and hard to maintain.
Run 3
The code has severe readability issues. Every method contains a redundant and confusing always-false assertion (e.g., `if (((0xFAFB ^ 0xFAFB) != 0)) { throw new AssertionError(); }`) that adds noise and obscures intent. Indentation is inconsistent — constructor and method bodies are not properly indented, disrupting logical structure and reading flow. The code is heavily nested with multiple method calls on a single line, reducing clarity and violating one-action-per-line granularity. While method names are descriptive and the overall architecture is reasonable, these positives are overshadowed by formatting problems and meaningless constructs. The code would benefit from removing the no-op assertions, applying consistent formatting, and breaking chained calls into intermediate variables for clarity.
Run 1
Code Structure: Methods are logically separated by responsibility, with a shared partition-validation helper. Nesting: Mostly flat, with simple guards and a short conditional chain. Clarity of intent: Descriptive names and isolation-level comments explain the legitimate operations, but repeated, always-false hexadecimal XOR assertions introduce confusing noise. Code length: Methods are short, though duplicated timestamp-fetch logic and pointless assertions add unnecessary length. Action granularity: Most statements perform one action per line, but inline assertion blocks combine conditions and throws, while chained API calls require additional parsing. Reading flow: The overall class organization is natural, but unindented assertions interrupt every method and inconsistent brace usage reduces visual consistency.
Run 2
Code Structure: Well-organized interface implementation with focused methods and a shared partition-validation helper. Nesting: Shallow conditionals and straightforward returns keep complexity low. Clarity of intent: Descriptive names and useful comments explain the metadata operations, but repeated hexadecimal XOR checks that are always false introduce confusing, purposeless noise. Code length: Mostly concise, though redundant assertion checks and duplicated timestamp-fetch logic add unnecessary length. Action granularity: Most statements perform one action per line; compressed assertion blocks combine conditions and throws on a single line. Reading flow: Methods follow a natural fetch, validate, return sequence, but unindented checks repeatedly interrupt that flow. Long calls and exception-message lines, inconsistent brace usage, and tightly packed imports further reduce readability.
Run 3
Code Structure: Well-organized into focused methods, with a shared partition lookup helper, although timestamp-fetching logic is repeated. Nesting: Shallow conditionals and straightforward returns keep complexity low. Clarity of intent: Descriptive names, explicit exceptions, and useful comments explain the main behavior, but unexplained hexadecimal XOR checks that always evaluate to false introduce distracting noise. Code length: Mostly concise, though repeated dead assertions and similar offset-fetching methods add unnecessary length. Action granularity: Most meaningful operations occupy separate lines; the compressed assertion statements combine conditions and throws on one line. Reading flow: Method ordering and delegation are natural, but unindented assertions interrupt every method, and inconsistent brace usage slightly weakens visual consistency.