Sample
int-fcf345420c1e-I06
Invert eligible conditions and exchange their branches
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.836 | 0–1; higher is more readable |
| Dorn | 0.652 | 0–1; higher is more readable |
| Mi | 0.086 | 0–1; higher is more readable |
| LLOC | 50 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 11 | 0–20; mean of three runs |
| GPT-6.1 Sol | 13 | 0–20; mean of three runs |
| BTTF | 0.539 | 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. | 3416.592 | −112.748 |
| Source linesThe number of non-empty source lines. | 162 | +64.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. | 4.587 | −6.881 |
Intercept 8.87 + feature contributions = -45.958 (log-odds).
Score = sigmoid(-45.958) = 0.
| Score | 0.836 |
|---|
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. | 163 | −4.735 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 107 | +2.964 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 161.81 | +1.852 |
| 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.945 | −1.415 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 115.656 | +1.062 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.052 | +0.435 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = 0.63 (log-odds).
Score = sigmoid(0.63) = 0.652.
| Score | 0.086 |
|---|
| Score | 50 |
|---|
Run 1
The code has some good elements: clear Javadoc, logical class organization, and descriptive method names. However, it is severely undermined by bizarre conditional patterns like `if (!((condition))) {} else { ... }`, which inverts logic and makes the code hard to follow. These patterns appear consistently throughout, suggesting either obfuscation or an automated transformation. The anonymous inner listener and nested Runnable add complexity, though the nesting level is manageable. The intent of the class is clear, but the actual implementation of conditional logic is ambiguous and unnatural. Action granularity is mixed—some lines do too much, while the inverted conditionals spread a single logical action across multiple lines with empty blocks. Overall, the code works but reads as if deliberately made less maintainable despite its structural clarity.
Run 2
The code has good documentation and logical structure, but readability is significantly hurt by inverted conditional patterns like `if (!((condition))) {} else { ... }` throughout. These empty-if blocks with logic in else clauses are confusing and non-idiomatic. The anonymous inner listener class adds nesting and obscures the main flow. Method names like `operationComplete0` are unclear. The class is concise overall, but the action granularity suffers—multiple operations are packed into conditionals awkwardly. While the purpose is clear from Javadoc, the implementation's intent is muddied by these anti-patterns. The code would be much more readable with straightforward `if (condition) { ... }` statements and breaking the listener logic into clearer methods.
Run 3
The code has clear documentation and logical class structure, with methods that are generally short and purposeful. However, readability is significantly hurt by unnatural inverted conditional patterns (e.g., `if (!condition) {} else { ... }`) that obscure intent and disrupt reading flow. The listener's operationComplete method contains a nested anonymous Runnable with inner logic, adding unnecessary depth. Several methods could be more concise, and the inversion of boolean checks adds cognitive overhead. Action granularity is mostly fine, but the overall flow feels awkward due to these stylistic choices.
Run 1
Code Structure: Well-organized class with focused methods separating registration, completion, and validation. Nesting: Mostly shallow, although anonymous listener and Runnable classes add depth. Clarity of intent: Descriptive names and thorough documentation explain promise aggregation, but negated conditions, redundant parentheses, and empty if branches obscure straightforward checks. Code length: Methods are concise; repetitive documentation and deprecated overloads increase overall length. Action granularity: Generally one action per line, but compact empty-if/else constructs reduce visual clarity. Reading flow: Method organization and consistent formatting support navigation, while inverted conditional logic repeatedly interrupts natural reading. Overall, the design is understandable, but unnecessarily convoluted conditionals significantly reduce readability.
Run 2
Code Structure: Well organized into focused methods, with separate validation and completion helpers. Nesting: Mostly shallow, though anonymous listener and Runnable classes add depth. Clarity of intent: Descriptive names and thorough documentation explain aggregation behavior, but inverted conditions with empty if branches, redundant parentheses, and double negations obscure straightforward checks. Code length: Implementation methods are concise; extensive, partly repetitive documentation and deprecated overloads increase overall length. Action granularity: Generally one action per line, but empty if/else constructs compress control syntax awkwardly. Reading flow: Public methods follow a sensible lifecycle, and helper extraction supports comprehension; however, repeatedly translating negated conditions interrupts the otherwise natural flow.
Run 3
Code Structure: Well-organized class with distinct methods for adding futures, finishing aggregation, and validating state. Nesting: Most methods are shallow, but anonymous listener and Runnable classes introduce deeper nesting. Clarity of intent: Descriptive names and thorough documentation clarify the purpose; negated conditions, redundant parentheses, and empty if branches followed by meaningful else blocks substantially obscure straightforward checks. Code length: Implementation methods are concise, though repetitive documentation and deprecated overloads increase length. Action granularity: Generally one action per line, but inline empty branches compress conditional structure awkwardly. Reading flow: Public operations and private helpers follow a reasonable sequence, yet inverted conditional patterns repeatedly interrupt natural reading and require mentally reconstructing the intended logic.