Sample
int-ab32ff944260-I12
Inline all eligible single-use intermediate local 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 well-structured and highly readable. It follows a logical organization, with fields grouped at the top, constructors, public API methods, and private helpers clearly separated. Nesting is minimal: the deepest nesting occurs in the listener callback, but it is justified by the asynchronous execution handling. Intent is clear due to descriptive method and variable names, along with comprehensive Javadoc comments explaining usage and constraints. Code length is reasonable, with no obvious redundancy except for the deprecated overloads, which are necessary for backward compatibility. Action granularity is mostly one action per line, though some dense lines (e.g., ternary in tryPromise, inline listener definition) slightly reduce readability. Reading flow is natural, with methods ordered from construction through usage to completion logic. Overall, the code is maintainable and understandable.
Run 3
The code is highly readable with clear structure and intent. The class has a single well-defined responsibility, and methods are logically organized with clear separation of concerns. Javadoc comments thoroughly explain usage, constraints, and edge cases. Nesting is mostly flat—the deepest nesting is two levels inside the listener, which is acceptable. Clarity of intent is strong due to descriptive method names like checkAddAllowed() and checkInEventLoop(). Code length is appropriate, avoiding unnecessary verbosity while maintaining completeness. Action granularity is mostly one action per line, though some conditionals combine operations. The reading flow is natural, moving from field declarations to constructors and public methods to private helpers. Minor deductions are for the anonymous listener class (which adds some indirection) and the deprecated methods that slightly clutter the public API.
Run 1
Code Structure: Well-organized class with focused methods and separate validation helpers, although the listener implementation interrupts the field declarations. Nesting: Most methods are flat; nested anonymous listener and Runnable classes add localized depth. Clarity of intent: Descriptive names and comprehensive documentation clearly explain aggregation, failure handling, and threading constraints; tryPromise is slightly vague. Code length: Implementation methods are concise, but repetitive Javadoc and deprecated overloads increase reading volume. Action granularity: Statements generally perform one action per line, with a compact, understandable ternary for completion. Reading flow: Consistent formatting and straightforward validation-to-action sequences support natural reading, though asynchronous callbacks and shared counters require some cross-referencing.
Run 2
Code Structure: Well organized into focused methods, with validation and completion logic separated. Nesting: Mostly shallow, although the listener containing an anonymous Runnable introduces noticeable nesting. Clarity of intent: Descriptive fields, method names, and thorough documentation clearly explain aggregation and thread constraints; tryPromise is slightly vague. Code length: Implementation methods are concise, but repetitive documentation and deprecated overloads increase reading overhead. Action granularity: Statements generally perform one action per line, making state changes easy to follow. Reading flow: Public operations and private helpers form a logical sequence, though the substantial listener near the top and asynchronous dispatch require readers to connect completion logic with add and finish. Overall, highly readable with modest verbosity and callback complexity.
Run 3
Code Structure: Well-organized class with focused public methods and extracted validation helpers, although the substantial listener implementation precedes constructors. Nesting: Most methods are flat; nested anonymous listener and Runnable classes add localized complexity. Clarity of intent: Descriptive names and comprehensive documentation clearly explain aggregation, failure handling, and threading requirements; operationComplete0 and tryPromise are less descriptive. Code length: Implementation methods are concise, but repetitive documentation and deprecated overloads increase overall length. Action granularity: Statements generally perform one action per line, making state changes and validation easy to follow. Reading flow: Consistent formatting and straightforward add/finish workflows support natural reading, though asynchronous callbacks, shared counters, and the listener's placement require some cross-referencing.