Sample
int-3ccbcf831469-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.653 | 0–1; higher is more readable |
| Dorn | 0.216 | 0–1; higher is more readable |
| Mi | 0.635 | 0–1; higher is more readable |
| LLOC | 103 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 7.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 12.33 | 0–20; mean of three runs |
| BTTF | 0.416 | 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. | 7959.136 | −262.651 |
| Source linesThe number of non-empty source lines. | 188 | +75.2 |
| 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.948 | −7.423 |
Intercept 8.87 + feature contributions = -186.004 (log-odds).
Score = sigmoid(-186.004) = 0.
| Score | 0.653 |
|---|
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. | 188 | −5.62 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 181 | +5.523 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 180 | −3.71 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 187.845 | +2.216 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 95.947 | +0.744 |
| 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. | 95.942 | −0.399 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.109 | −0.115 |
Intercept 0.07 + feature contributions = -1.29 (log-odds).
Score = sigmoid(-1.29) = 0.216.
| Score | 0.635 |
|---|
| Score | 103 |
|---|
Run 1
The code is nearly unreadable due to the injection of nonsensical, repetitive dead code lines at the start of every method and constructor: `if (((0xC977 ^ 0xC977) != 0)) { throw new AssertionError(); }`. This fragment, which always evaluates to false, obscures the actual logic, destroys the natural reading flow, and makes every block start with an identical, confusing line. Structure and intent are buried under this noise, and action granularity is disrupted because each logical operation is preceded by a meaningless conditional. While the original skeleton appears reasonably structured, the pervasive artificial clutter reduces clarity to almost zero, making intent ambiguous and the code unnecessarily long.
Run 2
The code is generally well-structured and readable. It follows a clear logical organization with a main class and two inner classes handling serialization and hashing. Nesting is mostly flat, with the deepest at two levels in the try-catch and conditional logic. Intent is clear for most methods, though the purpose of 'supportsClone' method could be more explicit. Code length is appropriate, and action granularity mostly follows one action per line. Reading flow is natural. However, several issues reduce readability: conditional statements are followed by assertions on the same line without proper indentation, making them visually ambiguous. The inconsistent indentation in constructor bodies is jarring. The fall-through pattern in 'newHasher' could be clearer. The use of ternary in 'hash()' with method calls is a bit dense but acceptable. Overall, the code is readable but the formatting inconsistencies prevent a higher score.
Run 3
The code suffers from significant readability issues. The most glaring problem is the insertion of meaningless dead code lines like 'if (((0xC977 ^ 0xC977) != 0)) { throw new AssertionError(); }' at the start of nearly every method. These add no value, disrupt reading flow, and obscure the actual logic. The code structure is otherwise logical, using nested static classes appropriately for serialization and hashing. Nesting is minimal, mostly limited to try-catch blocks. Clarity of intent is severely undermined by the obfuscated dead code; without it, the class's purpose as a MessageDigest adapter would be clear. Code length is unnecessarily inflated by the repeated dead code checks. Action granularity is reasonable—one primary action per line—but the reading flow is constantly interrupted. Overall, the core implementation is straightforward, but the pervasive artificial clutter makes the code extremely difficult to read.
Run 1
Code Structure: Responsibilities are logically separated into digest creation, hashing, and serialization helpers. Nesting: Generally shallow, with only modest nesting in cloning and exception handling. Clarity of intent: Descriptive names and comments explain the adapter, but repeated always-false hexadecimal XOR guards introduce confusing, purposeless logic. Code length: Core methods are concise, yet redundant guards unnecessarily inflate nearly every method. Action granularity: Most meaningful statements perform one action per line; injected guards compress conditions and throws onto single lines. Reading flow: Method organization is natural, but unindented guards repeatedly interrupt otherwise consistent formatting and force readers to distinguish real behavior from noise.
Run 2
Code Structure: Logical separation into the hash-function adapter, serialization helper, and hasher keeps responsibilities organized. Nesting: Mostly shallow; the clone fallback adds only moderate nesting. Clarity of intent: Descriptive names and focused methods explain the hashing behavior, but repeated always-false hexadecimal XOR checks introduce distracting, unexplained noise. Code length: Core implementation is reasonably concise, yet redundant checks unnecessarily lengthen nearly every method. Action granularity: Most meaningful operations occupy separate lines, while injected checks compress conditions and throws onto one line. Reading flow: Normal method organization and consistent core formatting support scanning, but unindented checks repeatedly interrupt the flow. Overall, the underlying design is readable, substantially weakened by pervasive obfuscation-like boilerplate.
Run 3
Code Structure: Logical separation into the hash-function adapter, serialization proxy, and hasher keeps responsibilities organized. Nesting: Mostly shallow, with only modest nesting in clone handling. Clarity of intent: Descriptive names, standard digest operations, and lifecycle checks convey purpose, but repeated always-false hexadecimal XOR guards introduce confusing, irrelevant logic. Code length: Functional methods are concise, yet unnecessary guards substantially inflate the code. Action granularity: Most meaningful statements perform one action per line; inline guard-and-throw blocks break that consistency. Reading flow: Method ordering and delegation are natural, but unindented guards at every method entry repeatedly interrupt scanning and obscure otherwise straightforward implementation.