Sample
int-3d60b5b0aed1-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.848 | 0–1; higher is more readable |
| Dorn | 0.244 | 0–1; higher is more readable |
| Mi | 0.468 | 0–1; higher is more readable |
| LLOC | 39 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16 | 0–20; mean of three runs |
| GPT-6.1 Sol | 14.67 | 0–20; mean of three runs |
| BTTF | 0.398 | 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. | 2769.72 | −91.401 |
| Source linesThe number of non-empty source lines. | 142 | +56.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. | 4.678 | −7.017 |
Intercept 8.87 + feature contributions = -32.748 (log-odds).
Score = sigmoid(-32.748) = 0.
| Score | 0.848 |
|---|
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. | 143 | −4.027 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 72 | +1.753 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 141.792 | +1.572 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 72 | −1.231 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 95.804 | +0.741 |
| 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.986 | −0.57 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.039 | +0.561 |
Intercept 0.07 + feature contributions = -1.13 (log-odds).
Score = sigmoid(-1.13) = 0.244.
| Score | 0.468 |
|---|
| Score | 39 |
|---|
Run 1
The code is well-structured with clear documentation, logical field grouping, and straightforward constructors. There are some odd injected lines (e.g., 'if (((0x94DB ^ 0x94DB) != 0)) { throw new AssertionError(); }') that add visual noise and hurt readability. Nesting is minimal, and each method has a clear purpose. Action granularity is mostly one action per line. The safe range logic is slightly opaque due to the swapped min/max values, but comments explain the intent. Overall, it's readable but slightly marred by the redundant assertion lines.
Run 2
The code is well-structured with clear class-level documentation and logical field grouping. Nesting is minimal, with only a few shallow conditional checks. Intent is generally clear through descriptive field/method names and Javadoc. However, readability is hurt by repeated suspicious `if (((0x...) != 0)) { throw new AssertionError(); }` lines that appear to be injected noise and do not belong. These break flow and confuse the reader. The code is concise overall, though the two-argument constructor has an unnecessary delegation. Action granularity is mostly one action per line, but the boolean condition in `escape(String)` is dense. Reading flow is natural except for the inserted dead-code checks. Removing those would improve clarity significantly.
Run 3
The code is generally well-structured with clear class-level Javadoc, logical constructor delegation, and flat, readable methods. Intent is clear: look up replacements, check safe ranges, and delegate unsafe escaping. However, readability is reduced by suspicious injected assertion lines (e.g., `if (((0x94DB ^ 0x94DB) != 0)) { throw new AssertionError(); }`) that add noise and confuse intent. Nesting is minimal, and most actions are one per line, but some conditionals in `escape` and `escape(String)` are densely packed. Reading flow is natural overall, but the injected checks disrupt it and make the code harder to trust at a glance. The code is concise and action granularity is mostly good, with only minor complexity in conditionals.
Run 1
Code Structure: Fields, constructors, and escaping methods are logically organized, but repeated dead assertion checks introduce unrelated clutter. Nesting: Control flow is shallow, with only a loop and modest nested conditionals. Clarity of intent: Descriptive names and thorough documentation clearly explain replacement lookup and safe-range handling; constant XOR checks obscure intent without adding meaningful behavior. Code length: Functional methods are concise, though repetitive documentation and redundant assertions inflate the class. Action granularity: Most statements perform one action per line, but inline assertion blocks combine conditions and throws on a single line. Reading flow: The main escaping logic reads naturally, with straightforward early returns, but unindented injected checks and inconsistent blank spacing repeatedly interrupt the flow.
Run 2
Code Structure: Fields, constructors, and escaping methods are logically organized, but repeated meaningless assertion guards add clutter. Nesting: Generally shallow, with only a small nested conditional in character escaping. Clarity of intent: Descriptive names and thorough documentation explain replacement lookup and safe-range behavior; hexadecimal XOR checks obscure intent despite always being false. Code length: Core implementation is concise, though redundant guards and overlapping constructor documentation increase length unnecessarily. Action granularity: Most statements perform one action per line, but injected guards compress conditions and throws onto single lines. Reading flow: Method ordering and early returns support natural reading, while unindented guards, excess blank lines, and dense compound conditions interrupt it.
Run 3
Code Structure: Fields, constructors, and escaping methods are logically organized, but repeated irrelevant assertion checks clutter otherwise cohesive code. Nesting: Shallow loops and conditionals keep control flow easy to follow. Clarity of intent: Descriptive names and thorough documentation explain replacement lookup and safe-range handling; constant XOR checks obscure intent because they can never trigger. Code length: Implementation is reasonably concise, though duplicated constructor documentation and dead checks add unnecessary length. Action granularity: Most lines contain one action, but inline assertion conditionals combine branching and throwing on a single line. Reading flow: Method ordering and early returns support natural reading, while unindented injected checks, inconsistent spacing, and extra blank lines interrupt it.