Sample
int-3b96cadc4a2f-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.767 | 0–1; higher is more readable |
| Dorn | 0.25 | 0–1; higher is more readable |
| Mi | 0.259 | 0–1; higher is more readable |
| LLOC | 73 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 2.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 12.67 | 0–20; mean of three runs |
| BTTF | 0.455 | 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. | 4956.535 | −163.566 |
| Source linesThe number of non-empty source lines. | 150 | +60 |
| 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.745 | −7.117 |
Intercept 8.87 + feature contributions = -101.813 (log-odds).
Score = sigmoid(-101.813) = 0.
| Score | 0.767 |
|---|
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. | 149 | −4.239 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 135 | +3.932 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 117 | −2.264 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 149.198 | +1.676 |
| 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. | 119.954 | −1.416 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 116.868 | +1.081 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.091 | +0.06 |
Intercept 0.07 + feature contributions = -1.099 (log-odds).
Score = sigmoid(-1.099) = 0.25.
| Score | 0.259 |
|---|
| Score | 73 |
|---|
Run 1
The code contains numerous bizarre, artificially injected lines like `if (((0xA3E3 ^ 0xA3E3) != 0)) { throw new AssertionError(); }` which disrupt every method, destroy reading flow, and obscure intent. These assertions are nonsensical (always false), add noise, and break action granularity by adding multiple separate statements at the start of methods. While the underlying class structure is simple, the pollution makes the code practically unreadable. Nesting is shallow, but code length is bloated by redundant assertion blocks. The comments explaining why readRetainedSlice/retainedSlice call non-retained variants are helpful, but are buried under the artificial clutter. The overall logical organization of the wrapper itself is fine, but the deliberate obfuscation overwhelms any clarity. Removing the injected assertion lines and the awkward merged `if` statement would leave a concise, readable class, but as presented it scores extremely poorly.
Run 2
The code's logical structure is simple, but readability is severely damaged by pervasive obfuscation. Nearly every method contains a nonsensical assertion like `if (((0xA3E3 ^ 0xA3E3) != 0)) { throw new AssertionError(); }` that evaluates to false and serves no purpose other than to distract and confuse. This clutters every method, obscuring the actual intent. Nesting is minimal, but the constant interruptions break the reading flow and make the code unnecessarily long. Action granularity is poor—each method is bloated with redundant lines. Comments in some methods are helpful, but the surrounding noise undermines their value. The class's purpose (wrapping a ByteBuf to prevent reference count changes) is clear from the header and method names, but the implementation is polluted, making it hard to follow. Without the bogus assertions, this would be highly readable; as written, it is painful to maintain.
Run 3
The code is severely obfuscated with meaningless assertions on nearly every line (e.g., `if (((0xA3E3 ^ 0xA3E3) != 0)) { throw new AssertionError(); }`). These add no functional value and disrupt reading flow, making the actual logic hard to locate. The original structure is logical — a wrapper for ByteBuf — but the injected clutter destroys clarity of intent, increases code length unnecessarily, and violates action granularity and reading flow. Nesting is flat, but that is overshadowed by the repeated noise. The comments explaining slice/duplicate behavior are helpful but buried under the noise. Overall, the code is nearly unreadable, lacking maintainability and clarity despite the underlying straightforward design.
Run 1
Code Structure: The wrapper is logically organized into small, related overrides. Nesting: Control flow is shallow and easy to follow. Clarity of intent: Documentation, descriptive names, and explanatory comments clarify the unreleasable behavior, but repeated always-false XOR checks introduce confusing noise. Code length: Methods are concise, though redundant checks and repeated comments unnecessarily inflate the class. Action granularity: Most lines perform one action, but inline conditional throws and a chained assignment combine operations. Reading flow: Consistent method patterns help scanning, while unindented assertion checks repeatedly interrupt the otherwise natural flow.
Run 2
Code Structure: Methods are logically grouped in a focused wrapper class, with consistent overrides. Nesting: Control flow is shallow, and most methods simply delegate or return a constant. Clarity of intent: Class documentation, descriptive method names, and explanatory comments clarify reference-count behavior, but repeated always-false hexadecimal XOR checks introduce confusing, irrelevant logic. Code length: Functional methods are concise, but redundant checks and repeated comments unnecessarily expand the class. Action granularity: Most lines perform one action; inline conditional throws and a chained assignment slightly weaken this consistency. Reading flow: Related methods follow a natural sequence, but unindented assertion checks repeatedly interrupt the otherwise clean formatting and distract from the actual behavior.
Run 3
Code Structure: Methods are logically grouped within a focused wrapper class, with consistent overrides. Nesting: Control flow is shallow, and most methods simply delegate or return a value. Clarity of intent: Class documentation, descriptive method names, and comments explain reference-count protection, but repeated always-false hexadecimal XOR checks introduce misleading noise. Code length: Methods are short, yet redundant assertion checks and repeated explanatory comments unnecessarily expand the class. Action granularity: Most lines express one action, but inline conditional throws and a chained assignment combine operations. Reading flow: The delegation pattern is predictable, but unindented checks, excessive parentheses, and inconsistent spacing repeatedly interrupt scanning. Overall, the underlying implementation is understandable, while pervasive dead-code clutter substantially reduces readability.