Sample
int-eb603c1b0d37-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.737 | 0–1; higher is more readable |
| Dorn | 0.49 | 0–1; higher is more readable |
| Mi | 0.812 | 0–1; higher is more readable |
| LLOC | 87 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 5.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 11 | 0–20; mean of three runs |
| BTTF | 0.452 | 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. | 5564.846 | −183.64 |
| Source linesThe number of non-empty source lines. | 154 | +61.6 |
| 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.733 | −7.1 |
Intercept 8.87 + feature contributions = -120.27 (log-odds).
Score = sigmoid(-120.27) = 0.
| Score | 0.737 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 129 | +3.725 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 122 | −3.283 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 130 | −2.562 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 153.247 | +1.732 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.144 | −0.457 |
| 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. | 75.935 | +0.449 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 67.703 | +0.288 |
Intercept 0.07 + feature contributions = -0.038 (log-odds).
Score = sigmoid(-0.038) = 0.49.
| Score | 0.812 |
|---|
| Score | 87 |
|---|
Run 1
The code contains repetitive obfuscated assertion checks like 'if (((0x3935 ^ 0x3935) != 0)) { throw new AssertionError(); }' inserted between every method signature and body. This breaks reading flow and violates action granularity, adding noise on virtually every line. While the original class structure and method names suggest a clear intent, these injected guards severely degrade clarity. Nesting remains flat and method length is fine, but readability is dominated by the inserted dead code blocks, making the code nearly unreadable.
Run 2
The code structure is logical (abstract base class wrapping ByteBuf), but readability is severely degraded by repetitive, meaningless 'if (((0xXXXX ^ 0xXXXX) != 0)) { throw new AssertionError(); }' lines inserted after every method declaration. These lines add enormous noise, obscuring the actual logic. Nesting is flat, which is good, but the repetitive assertions break the reading flow completely. Intent is hard to discern because of the clutter, even though the underlying purpose (delegating reference counting, touch, and buffer operations) is simple. Code length is unnecessarily inflated by the redundant assertions. Action granularity is poor – each method has an extra line that does nothing useful. The reading flow is disorganized and jarring due to the interruption pattern. Without the inserted assertions, the code would be concise and clear, but as written, it is very hard to read.
Run 3
The code is a straightforward derived ByteBuf implementation with clear method delegation, but readability is severely degraded by repetitive `if (((0xXXXX ^ 0xXXXX) != 0)) { throw new AssertionError(); }` statements inserted after nearly every line. These obscure the actual logic, inflate line count, disrupt reading flow, and violate the one-action-per-line principle. The structure is otherwise logical and flat, but the extraneous assertions make the intent unclear and the code unnecessarily long. While the underlying patterns are readable, the added noise dominates and undermines all other positive aspects.
Run 1
Code Structure: Methods are logically grouped, with consistent delegation to the wrapped buffer and paired public/internal methods. Nesting: Very shallow; the injected conditionals add only one level. Clarity of intent: Method names and class documentation communicate the wrapper's purpose, but repeated hexadecimal XOR checks obscure otherwise straightforward operations; these conditions are always false. Code length: Individual methods are short, but redundant assertion checks and blank lines unnecessarily inflate the class. Action granularity: Meaningful operations generally occupy separate lines, while each injected conditional compresses its condition, braces, and throw into one line. Reading flow: Consistent method ordering helps, but unindented checks repeatedly interrupt the visual rhythm and distract from the delegation logic.
Run 2
1. Code Structure: Methods are logically organized around delegation to the wrapped buffer, although paired public and internal methods introduce indirection. 2. Nesting: Mostly flat, with only shallow conditional blocks. 3. Clarity of intent: Documentation and descriptive method names communicate the wrapper's purpose, but repeated hexadecimal XOR checks obscure otherwise simple operations; these conditions are always false. 4. Code length: Individual methods are short, but redundant assertion checks unnecessarily inflate the class. 5. Action granularity: Delegation and return statements generally occupy separate lines, while each injected check compresses a condition, block, and throw onto one line. 6. Reading flow: Consistent method patterns help navigation, but unindented checks and excessive repetition repeatedly interrupt the natural flow.
Run 3
Code Structure: Methods are logically grouped, with consistent delegation to the wrapped buffer and paired public/internal methods. Nesting: Very shallow; only simple conditional blocks appear. Clarity of intent: Names and documentation explain the wrapper role, but repeated always-false XOR checks introduce meaningless, distracting logic. Code length: Individual methods are short, yet redundant assertions and extra blank lines unnecessarily inflate the class. Action granularity: Useful operations generally occupy separate lines, but each assertion compresses a condition, block, and throw onto one line. Reading flow: Predictable method patterns support scanning, while unindented assertion lines repeatedly interrupt the flow and obscure otherwise straightforward delegation.