Sample
int-9dac1e2d6bb6-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.761 | 0–1; higher is more readable |
| Dorn | 0.108 | 0–1; higher is more readable |
| Mi | 0.079 | 0–1; higher is more readable |
| LLOC | 76 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 6.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 12.67 | 0–20; mean of three runs |
| BTTF | 0.435 | 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. | 5257.336 | −173.492 |
| 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.722 | −7.084 |
Intercept 8.87 + feature contributions = -96.506 (log-odds).
Score = sigmoid(-96.506) = 0.
| Score | 0.761 |
|---|
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. | 189 | −5.656 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 133 | +3.863 |
| 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. | 187.793 | +2.215 |
| 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.963 | −1.416 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 115.624 | +1.061 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.064 | +0.317 |
Intercept 0.07 + feature contributions = -2.107 (log-odds).
Score = sigmoid(-2.107) = 0.108.
| Score | 0.079 |
|---|
| Score | 76 |
|---|
Run 1
The code has a clear overall structure with a well-documented class purpose and logical method organization, but readability is severely compromised by the bizarre insertion of dead-code assertions like 'if (((0xC9A ^ 0xC9A) != 0)) { throw new AssertionError(); }' throughout. These lines add noise and break the natural reading flow. Nesting is moderate (listener inner class with conditional threading logic), but the inline AssertionError lines cause vertical bloat. Naming is generally clear (expectedCount, doneCount, aggregatePromise), and intent is understandable from comments, but the 'operationComplete0' method could be restructured for clarity. Public methods are concise, but the repetitive dead-code checks inflate length. The code demonstrates reasonable action granularity otherwise, but the artificial corruption makes it feel tangled and unreadable.
Run 2
The code has a clear class-level purpose and reasonable method separation, but readability is severely damaged by formatting and clutter. The structure includes a listener inner class and helper methods, which is logical, though the class is not overly tangled. However, nearly every method begins with an unexplained obfuscated assertion line (`if (((0x...) != 0)) { throw new AssertionError(); }`) that adds noise, breaks the natural reading flow, and obscures intent. Method bodies are mostly one action per line, which is good, but the constant interruption hurts granularity and clarity. The Javadoc and method names are helpful, but the overall impression is that the code has been deliberately obfuscated, making it much harder to read than necessary. The nesting is moderate, with only a few levels in the listener logic, but the style choices dominate the evaluation. Concise lines and logical organization are overshadowed by visual clutter and unclear artifact lines, preventing the code from being considered highly readable.
Run 3
This code is significantly obfuscated and unreadable. The most egregious issue is the insertion of nonsensical conditional statements like 'if (((0xC9A ^ 0xC9A) != 0)) { throw new AssertionError(); }' after every method declaration and inside anonymous classes. These serve no logical purpose and disrupt the reading flow, making it difficult to follow the actual logic. While the base class structure appears logical and the Javadoc comments are detailed, the code is littered with dead code and meaningless assertions that obscure the intent. Nesting is moderate, but the random 'if' blocks add unnecessary complexity. The action granularity is violated by placing method calls and these assertion checks on the same line. Overall, the code appears deliberately modified to be hard to read, failing to meet the criteria for clarity of intent, code structure, and reading flow.
Run 1
Code Structure: Well-separated methods organize registration, completion tracking, validation, and aggregate notification. Nesting: Most methods are shallow, although anonymous listener and Runnable classes add depth. Clarity of intent: Descriptive names and thorough documentation explain the promise-combining lifecycle, but repeated always-false hexadecimal XOR checks introduce confusing, purposeless noise. Code length: Core logic is concise; redundant checks, repeated documentation, and deprecated overloads lengthen the class. Action granularity: Meaningful operations generally occupy separate lines, but injected checks compress conditions and throws onto single lines. Reading flow: The lifecycle is reasonably natural to follow, yet unindented checks repeatedly interrupt it, and asynchronous callbacks require some navigation.
Run 2
Code Structure: Responsibilities are logically separated into short methods, though the anonymous listener adds complexity. Nesting: Most methods are shallow; the listener and nested Runnable introduce moderate nesting. Clarity of intent: Descriptive names and thorough documentation explain aggregation and threading requirements, but repeated hexadecimal XOR checks obscure otherwise straightforward logic. Code length: Core operations are concise, while redundant always-false assertions and repetitive documentation unnecessarily expand the class. Action granularity: Most meaningful statements perform one action per line; injected checks compress conditions and throws onto single lines. Reading flow: The API and helper methods follow a coherent progression, but unindented assertion checks repeatedly interrupt visual consistency and distract from the actual behavior.
Run 3
Code Structure: Cohesive class with small, logically separated methods and clear state fields. Nesting: Mostly shallow, although the anonymous listener and nested Runnable introduce additional depth. Clarity of intent: Descriptive names and thorough documentation explain promise aggregation well, but repeated always-false hexadecimal XOR checks add confusing, purposeless noise. Code length: Core logic is concise; redundant checks and repetitive documentation unnecessarily expand the code. Action granularity: Most meaningful operations occupy separate lines, but injected checks compress conditions and throw statements onto single lines. Reading flow: The add, completion, and finish lifecycle is understandable, yet unindented checks repeatedly interrupt otherwise consistent formatting and natural flow.