Sample
int-fed04478c9a5-I11
Split eligible integer literals into pairs of short-named intermediate variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.84 | 0–1; higher is more readable |
| Dorn | 0.667 | 0–1; higher is more readable |
| Mi | 0.085 | 0–1; higher is more readable |
| LLOC | 50 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.562 | 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. | 3071.679 | −101.365 |
| 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.575 | −6.862 |
Intercept 8.87 + feature contributions = -34.558 (log-odds).
Score = sigmoid(-34.558) = 0.
| Score | 0.84 |
|---|
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.86 | +1.853 |
| 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.045 | +0.501 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = 0.697 (log-odds).
Score = sigmoid(0.697) = 0.667.
| Score | 0.085 |
|---|
| Score | 50 |
|---|
Run 1
The code is well-structured with clear logical organization: fields, listener, constructors, public API methods, and private helpers are grouped sensibly. Nesting is generally flat, with the deepest level being three (listener -> operationComplete -> executor.execute -> Runnable), which is acceptable. Intent is explicit through meaningful names and thorough Javadoc. Code length is appropriate, though some deprecated overloads add slight verbosity. Action granularity is mostly one action per line, enhancing readability. Reading flow is natural, with public methods following constructors and private helpers at the end. Minor issues: the listener's nested Runnable slightly increases depth, and raw type usage with @SuppressWarnings detracts slightly from clarity.
Run 2
The code is highly readable. It has a clear logical structure with a single-purpose class, well-documented public methods, and private helper methods that encapsulate validation. The nesting is shallow, mostly one level, except inside the anonymous listener where the executor check adds one more level but remains clear. Naming is explicit (expectedCount, doneCount, checkAddAllowed). Each method performs a focused action, and lines generally represent one action. The reading flow is natural, moving from fields to constructors, then add methods, then finish. The Javadoc is comprehensive and clarifies intent, especially about thread-safety and failure semantics. Minor deductions are due to some duplication in method overloads for deprecated types and the slightly dense assertion checks, but overall the code is easy to follow.
Run 3
The code is generally readable and well-structured. The class has a clear single responsibility and Javadoc explains the purpose and thread-safety constraints. Methods are small and focused, with one logical action per line. Nesting is mostly flat, except for the anonymous listener’s operationComplete method, which uses a simple if-else and an inner Runnable—acceptable but slightly deeper. Naming is clear (e.g., expectedCount, doneCount, checkAddAllowed). The only minor readability issues are the long Javadocs and a few deprecated overloads that add slight noise. Overall, the structure and flow make the logic easy to follow.
Run 1
Code Structure: Well-organized class with focused public methods and reusable validation helpers; the large listener initializer slightly interrupts organization. Nesting: Most methods are flat, though anonymous listener and Runnable classes create deeper nesting. Clarity of intent: Descriptive names and thorough documentation clearly explain aggregation, failure handling, and threading requirements; tryPromise is somewhat vague. Code length: Implementation methods are concise, but repeated documentation and deprecated overloads increase reading overhead. Action granularity: Statements generally perform one action per line; the compact ternary in tryPromise remains understandable. Reading flow: Registration, completion tracking, and final notification follow a coherent lifecycle, although asynchronous callbacks and mutable counters require some cross-referencing.
Run 2
Code Structure: Well organized into constructors, public operations, and focused validation/completion helpers, although the substantial listener implementation precedes the constructors. Nesting: Most methods are flat; nested anonymous listener and Runnable classes add localized complexity. Clarity of intent: Descriptive names and thorough documentation explain aggregation, failure handling, and threading constraints; operationComplete0 and tryPromise are less expressive. Code length: Implementation methods are concise, but repeated documentation and deprecated overloads increase overall length. Action granularity: Statements generally perform one action per line, with no compressed multi-statement lines. Reading flow: Consistent formatting and a natural add-to-finish lifecycle make the code easy to follow, though asynchronous callbacks and shared counters require tracking state across methods.
Run 3
Code Structure: Logically organized around adding futures, tracking completion, and resolving the aggregate promise, with validation extracted into helpers. Nesting: Most methods are flat, but the anonymous listener containing an anonymous Runnable creates a locally deep section. Clarity of intent: Descriptive field names, focused methods, and thorough documentation clearly explain aggregation and threading requirements; tryPromise is somewhat vague. Code length: Implementation methods are concise, although repeated documentation and deprecated overloads increase reading overhead. Action granularity: Statements generally perform one action per line, making state changes easy to follow. Reading flow: The public API and private helpers follow a sensible progression, but placing callback logic before constructors and using raw types and casts slightly interrupt readability.