Sample
int-d59d39eada4d-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.529 | 0–1; higher is more readable |
| Dorn | 0.108 | 0–1; higher is more readable |
| Mi | 0.719 | 0–1; higher is more readable |
| LLOC | 100 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 4.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 12.33 | 0–20; mean of three runs |
| BTTF | 0.38 | 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. | 9359.621 | −308.867 |
| Source linesThe number of non-empty source lines. | 215 | +86 |
| Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value. | 5.273 | −7.91 |
Intercept 8.87 + feature contributions = -221.907 (log-odds).
Score = sigmoid(-221.907) = 0.
| Score | 0.529 |
|---|
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. | 216 | −6.612 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 204 | +6.319 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 204 | −4.26 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 214.729 | +2.592 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 105.935 | +0.905 |
| 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. | 105.968 | −0.823 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.128 | −0.306 |
Intercept 0.07 + feature contributions = -2.115 (log-odds).
Score = sigmoid(-2.115) = 0.108.
| Score | 0.719 |
|---|
| Score | 100 |
|---|
Run 1
The code structure is fundamentally compromised by the pervasive insertion of meaningless `if (((0x... ^ 0x...) != 0)) { throw new AssertionError(); }` statements. These statements force a new line for what should be a single action, disrupting the reading flow and making the code unnecessarily long. While the underlying class logic is simple and the nesting is flat, the constant interruptions make it extremely difficult to discern the actual purpose of each method. The clarity of intent is destroyed because the reader's attention is diverted from the business logic (like caching or throwing `UnsupportedOperationException`) to deciphering the nonsensical XOR checks. This results in poor action granularity, as the redundant `if` statement adds an additional action to every method.
Run 2
The code structure is logically organized as a read-only wrapper around HttpHeaders, but readability is severely degraded by the repetitive obfuscated 'if (((0xXXXX ^ 0xXXXX) != 0)) { throw new AssertionError(); }' lines inserted before nearly every method body. These lines add no functional value and disrupt reading flow. Nesting is minimal, which is good, and intent is generally clear (e.g., caching, throwing UnsupportedOperationException for mutators). However, the code becomes unnecessarily long and cluttered due to the repeated AssertionError checks. Action granularity is mostly one action per line, but the presence of the obfuscated lines breaks this. The headerSet() method uses streams and collectors correctly but is somewhat dense. Overall, without the obfuscation, the code would be quite readable; with it, the score drops significantly.
Run 3
The code is severely compromised by injected obfuscation lines like 'if (((0x112F ^ 0x112F) != 0)) { throw new AssertionError(); }' inserted into nearly every method. These lines break action granularity and reading flow, making the code ambiguous and confusing. While the underlying class structure is logical and the intent of ReadOnlyHttpHeaders is clear, the repetitive, meaningless assertions dominate the reading experience. They force the reader to mentally filter out noise, increasing cognitive load and obscuring the actual logic. The remaining logic is concise and well-structured, but the overwhelming presence of the injected garbage lines makes the code effectively unreadable by human standards. Without those lines, the code would be highly readable (around 15-17), but as presented it is nearly impossible to evaluate normally.
Run 1
Code Structure: Small, clearly separated overrides provide logical organization, although read and mutation methods are somewhat interspersed. Nesting: Generally shallow; caching branches and the iteration loop are easy to follow. Clarity of intent: The class documentation, names, unmodifiable wrappers, and mutation exceptions clearly communicate read-only behavior. However, repeated always-false hexadecimal XOR checks introduce distracting, unexplained noise. Code length: Most methods are concise, but redundant checks unnecessarily inflate the class; explicit else blocks after returns add minor verbosity. Action granularity: Most meaningful statements perform one action per line, while injected checks compress conditions and throws onto single lines. Reading flow: Familiar override patterns support scanning, but unindented checks interrupt every method and weaken visual consistency. The collector expression requires extra attention but remains reasonably formatted.
Run 2
Code Structure: Logically organized into short overrides for cached reads, unmodifiable views, and rejected mutations. Nesting: Shallow, with simple conditionals and one loop; the collector expression adds modest complexity. Clarity of intent: Class documentation, descriptive names, and consistent exceptions clearly convey read-only behavior, but repeated always-false hexadecimal XOR checks introduce distracting, unexplained noise. Code length: Most methods are concise, and many overrides are justified, but redundant checks and excess blank lines unnecessarily inflate the class. Action granularity: Most meaningful operations occupy separate lines; injected checks compress conditions and throws onto single lines, while stream chaining combines several transformations. Reading flow: The overall progression is understandable, but unindented checks repeatedly interrupt scanning and undermine otherwise consistent formatting.
Run 3
Code Structure: Methods are logically organized around read-only header access, caching, and rejected mutations. Nesting: Mostly shallow, with simple conditionals and one loop; the collector expression is somewhat harder to parse. Clarity of intent: Class documentation, descriptive names, and unmodifiable wrappers clearly communicate purpose, but repeated always-false hexadecimal XOR checks introduce unexplained distractions. Code length: Most methods are concise, and override repetition is understandable, but the redundant assertion checks unnecessarily inflate the class. Action granularity: Functional statements generally perform one action per line, while the injected checks compress conditions and throws onto single lines. Reading flow: Consistent method patterns support scanning, but unindented checks repeatedly interrupt the otherwise natural flow. Removing those checks and simplifying caching branches would substantially improve readability.