Sample
int-daa1a34ec3bc-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.65 | 0–1; higher is more readable |
| Dorn | 0.121 | 0–1; higher is more readable |
| Mi | 0.276 | 0–1; higher is more readable |
| LLOC | 61 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 9 | 0–20; mean of three runs |
| GPT-6.1 Sol | 12 | 0–20; mean of three runs |
| BTTF | 0.454 | 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. | 8163.418 | −269.393 |
| Source linesThe number of non-empty source lines. | 210 | +84 |
| 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.78 | −7.171 |
Intercept 8.87 + feature contributions = -183.693 (log-odds).
Score = sigmoid(-183.693) = 0.
| Score | 0.65 |
|---|
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. | 210 | −6.399 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 171 | +5.178 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 171 | −3.503 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 209.94 | +2.525 |
| 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. | 115.991 | −1.248 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 115.9 | +1.066 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.063 | +0.332 |
Intercept 0.07 + feature contributions = -1.98 (log-odds).
Score = sigmoid(-1.98) = 0.121.
| Score | 0.276 |
|---|
| Score | 61 |
|---|
Run 1
The code is almost completely unreadable due to the pervasive presence of meaningless Obfuscated C constructs, like 'if (((0x3B87 ^ 0x3B87) != 0)) { throw new AssertionError(); }' on nearly every method. This destroys the natural reading flow and adds significant noise. While the class structure, constructor chaining, and Javadoc comments are standard and helpful, they are completely overshadowed by these injected lines. The overall structure is logical, but the constant interruption makes it impossible to follow. The code length is unnecessarily inflated, and the action granularity is broken, as a simple constructor call is followed by a bizarre conditional check. The code fails to meet even the most basic readability standards despite having a sound underlying design.
Run 2
The code is generally clear in intent with logical constructors and good Javadoc, but readability is harmed by repetitive dead-code assertions after every method (`if (((0x3B87 ^ 0x3B87) != 0)) { throw new AssertionError(); }`). These repetitive, identical checks break natural reading flow and add noise without purpose. Structure is reasonable with overloaded constructors delegating predictably, but the many constructors create repetitive length. Nesting is minimal, but the last method uses sequential if checks that could be more concise. Action granularity is mostly one action per line, though the dead-code assertion lines violate it. Overall, the core code is understandable but noisy and unnecessarily verbose.
Run 3
The code is a Java class with clear Javadoc comments and logical constructor delegation, but it is severely marred by repetitive and meaningless debug assertions like `if (((0x3B87 ^ 0x3B87) != 0)) { throw new AssertionError(); }` on nearly every method. These lines clutter the code, obscure intent, and destroy reading flow. The constructors are numerous and largely delegate to a superclass, which is reasonable, but the parameter lists are long and some methods lack Javadoc. Nesting is minimal, and action granularity is mostly one action per line, but the spurious assertions make the code unnecessarily long and confusing. Overall, structure and intent are partially readable, but the injected noise drastically lowers clarity and maintainability.
Run 1
Code Structure: Constructors are grouped logically, followed by operational methods and child creation; delegation keeps initialization organized. Nesting: Shallow conditionals and a single loop make control flow easy to follow. Clarity of intent: Descriptive names and Javadoc explain the class, but repeated always-false XOR assertions introduce confusing, purposeless noise, while positional Object arguments require interpretation. Code length: Numerous overloads are understandable API boilerplate, but redundant assertions and excess blank lines unnecessarily expand the code. Action granularity: Most meaningful statements perform one action per line; inline assertion blocks compress conditions and throws onto one line. Reading flow: Constructor delegation and straightforward methods support natural reading, but unindented assertions, inconsistent parameter alignment, and repetitive interruptions significantly impair scanning.
Run 2
Code Structure: Constructor overloads and lifecycle methods are logically grouped, with delegation reducing duplicated setup. Nesting: Control flow is shallow, using simple conditionals and one loop. Clarity of intent: Descriptive names and Javadoc explain the class, but repeated, always-false hexadecimal XOR checks introduce misleading noise; positional Object... arguments also obscure type expectations. Code length: Numerous overloads support configuration, but redundant assertion blocks and extra blank lines unnecessarily expand the code. Action granularity: Most meaningful statements perform one action per line, while injected checks compress conditions and throws onto single lines. Reading flow: Constructor delegation is predictable, but unindented assertion blocks, inconsistent parameter alignment, and repetitive checks repeatedly interrupt scanning.
Run 3
Code Structure: Constructors and methods are logically grouped, with straightforward delegation, but numerous overloads add repetition. Nesting: Shallow loops and independent conditionals keep control flow easy to follow. Clarity of intent: Descriptive names and Javadoc explain the NIO event-loop purpose, but repeated always-false hexadecimal XOR checks introduce unexplained noise; positional Object... arguments also obscure intent. Code length: Constructor overloads serve configuration needs, yet redundant assertions and repetitive documentation unnecessarily lengthen the class. Action granularity: Most meaningful operations occupy separate lines, but each injected assertion compresses a conditional and throw onto one line. Reading flow: Delegation and short methods support natural reading, while unindented assertions, inconsistent parameter alignment, and long signatures repeatedly interrupt it.