Sample
int-e936b3004815-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.499 | 0–1; higher is more readable |
| Dorn | 0.166 | 0–1; higher is more readable |
| Mi | 0.731 | 0–1; higher is more readable |
| LLOC | 93 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 6.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 12.67 | 0–20; mean of three runs |
| BTTF | 0.318 | 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. | 8146.228 | −268.826 |
| Source linesThe number of non-empty source lines. | 187 | +74.8 |
| 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.024 | −7.536 |
Intercept 8.87 + feature contributions = -192.691 (log-odds).
Score = sigmoid(-192.691) = 0.
| Score | 0.499 |
|---|
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. | 187 | −5.585 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 180 | +5.489 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 181 | −3.733 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 186.765 | +2.201 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 95.941 | +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. | 96.941 | −0.441 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.134 | −0.361 |
Intercept 0.07 + feature contributions = -1.616 (log-odds).
Score = sigmoid(-1.616) = 0.166.
| Score | 0.731 |
|---|
| Score | 93 |
|---|
Run 1
The code structure is logical with clear class hierarchy and implementation of SortedMultiset, but readability is severely impacted. The dominating issue is the obfuscated assertion pattern `if (((0x36D1 ^ 0x36D1) != 0)) { throw new AssertionError(); }` repeated at the start of nearly every method. These are dead code (always false) and create massive noise, breaking the natural reading flow between method signatures and their actual logic. Additionally, they add unnecessary vertical length and enforce a flat but cluttered appearance. The core logic itself—lazy initialization, delegation to forwardMultiset(), and reversal of comparator and bounds—is clear in intent and concise. Nesting is minimal, and action granularity is reasonable (one operation per line in key areas). However, the pervasive dead assertions and some formatting inconsistencies (e.g., missing indentation after method openings in some places) overwhelm the code's otherwise clean design. Without those inserted patterns, readability would be notably higher.
Run 2
The code is severely compromised by the repeated injection of meaningless null checks like 'if (((0x36D1 ^ 0x36D1) != 0)) { throw new AssertionError(); }' at the start of nearly every method. These statements are dead code, always evaluating to false, and they introduce massive noise, obscuring the actual logic. Every method is disfigured by this pattern, breaking reading flow and action granularity by adding an unrelated action before the real purpose. Structurally, the class itself is reasonably organized, and the underlying intent is clear—it's a standard skeleton for a descending multiset using lazy init and delegation—but the injected assertions ruin clarity. Nesting is otherwise flat, and the code length is normal for such a class, but the repetitive injected junk makes it read as tangled and obfuscated. Effectively unreadable despite the clean underlying design.
Run 3
The code has clear class-level documentation and logical method organization, but readability is severely degraded by an artificial pattern: nearly every method begins with an obfuscated assertion `if (((0x36D1 ^ 0x36D1) != 0)) { throw new AssertionError(); }`. This adds noise, destroys natural reading flow, and obscures intent. Nesting is generally flat, and action granularity is acceptable, but the repetitive irrelevant guards make methods appear longer and confusing. The actual logic—lazy initialization, delegation, and descending semantics—is reasonably structured, yet the unexplained assertion boilerplate dominates the reader’s experience. Without those lines, the code would rate much higher; as presented, clarity and readability suffer significantly.
Run 1
Code Structure: The class is logically organized into small overrides, cached views, and an entry-set implementation, but repetitive dead checks clutter every method. Nesting: Generally shallow; the local entry-set class adds modest nesting. Clarity of intent: Descriptive names and straightforward delegation clearly express descending-multiset behavior, while always-false hexadecimal XOR checks suggest misleading validation. Code length: Core methods are concise, but unnecessary assertions substantially inflate the class. Action granularity: Most meaningful statements perform one action; inline conditional throws and assignments embedded in returns make some lines harder to parse. Reading flow: Delegation and reversed operations read naturally, but unindented checks repeatedly interrupt the flow and undermine otherwise consistent formatting.
Run 2
Code Structure: Methods are logically separated, with consistent delegation and caching responsibilities. Nesting: Mostly shallow; the local entry-set class adds modest, justified nesting. Clarity of intent: Descriptive names and documentation make descending-view behavior understandable, but repeated always-false hexadecimal XOR checks introduce misleading noise. Code length: Core implementations are concise, yet unnecessary assertions substantially inflate the class. Action granularity: Most lines perform one action; inline conditional throws and assignments embedded in returns or ternaries combine operations. Reading flow: Delegation patterns are predictable, but unindented assertion lines repeatedly interrupt otherwise consistent formatting and natural flow.
Run 3
Code Structure: Logically organized around a descending multiset, with small delegation methods and localized caching. Nesting: Mostly shallow; the local entry-set class adds moderate, justified nesting. Clarity of intent: Descriptive names and documentation explain reversed operations, but repeated always-false hexadecimal XOR checks introduce misleading noise. Code length: Functional methods are concise, yet redundant assertion guards unnecessarily inflate the class. Action granularity: Most lines perform one action, but inline guard-and-throw statements and assignments embedded in returns compress multiple operations. Reading flow: Delegation patterns are predictable and method chains are formatted clearly; however, unindented guards interrupt nearly every method and undermine visual consistency.