Sample
int-732d2e4181a0-SRC
Unmodified source class
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.33 | 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 and readable, following common conventions for a utility class. The class has a clear single responsibility, and method names like add, addAll, finish, and checkInEventLoop clearly convey intent. Javadoc comments thoroughly explain usage, edge cases, and thread-safety requirements. Nesting is moderate, appearing mainly in the anonymous listener class. The listener's operationComplete method is slightly dense but still understandable. The overall flow is logical: public methods are organized first, followed by private helpers. Action granularity is generally good, though some lines like `return (cause == null) ? aggregatePromise.trySuccess(null) : aggregatePromise.tryFailure(cause);` pack multiple concepts. Deprecated methods are clearly marked, and ObjectUtil validations are correctly used. Minor readability deductions stem from raw type usage and the inherent complexity of the inner listener logic.
Run 2
The code is highly readable with clear structure, logical organization, and excellent documentation. Methods are small, single-purpose, and well-named. The nesting depth is minimal, mostly limited to one or two levels. Intent is clearly expressed through method names like checkAddAllowed(), checkInEventLoop(), and tryPromise(). Action granularity is good—each line performs a distinct operation. Reading flow follows a natural progression from listener definition, through constructors, to public API methods, and then private helpers. The only minor deductions are for the slightly complex anonymous listener class with its nested runnable and operationComplete0() method, which adds some cognitive overhead, and the deprecated method overloads that increase code length. Overall, this is production-quality, maintainable code.
Run 3
The code is well-structured and readable. It has clear separation of concerns with dedicated methods for logic, validation, and event handling. The nesting is shallow, and method names like checkAddAllowed, checkInEventLoop, and operationComplete0 clearly express intent. The class-level Javadoc provides useful context. However, there are minor readability issues: the listener field is defined before the executor it depends on, making field ordering slightly unnatural. The anonymous inner classes add some visual noise. The private operationComplete0 method is nested inside the listener implementation, which slightly disrupts the reading flow. Overall, it is concise, maintains good action granularity, and is easy to follow.
Run 1
Code Structure: Well-organized class with focused methods and separate validation helpers; placing the executor field after the listener slightly interrupts organization. Nesting: Most methods are flat, but nested anonymous listener and Runnable classes add visual depth. Clarity of intent: Descriptive names and thorough documentation clearly explain aggregation behavior and threading constraints; raw generic types and the operationComplete0 name are minor weaknesses. Code length: Implementation methods are concise, although repetitive documentation and deprecated overloads increase overall length. Action granularity: Statements generally perform one action per line; the compact ternary in tryPromise remains understandable. Reading flow: Consistent formatting and straightforward validation, registration, and completion logic support natural reading, though asynchronous callbacks require some backtracking to understand the lifecycle.
Run 2
Code Structure: Well-organized class with small public methods and focused validation helpers; the inline listener slightly interrupts the layout. Nesting: Most methods are flat, though nested anonymous listener and Runnable classes add visual depth. Clarity of intent: Descriptive fields, method names, and comprehensive documentation explain aggregation and threading constraints; operationComplete0 and tryPromise are less expressive names. Code length: Implementation is 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: Consistent formatting and straightforward add/finish operations support natural reading, although callback-driven completion requires tracking counters and state across methods.
Run 3
Code Structure: Well organized into focused API methods, validation helpers, and completion handling, although the large inline listener interrupts the field declarations. Nesting: Most methods are flat; nested anonymous listener and Runnable classes add localized depth. Clarity of intent: Descriptive names and thorough documentation explain aggregation behavior and threading constraints; operationComplete0 and tryPromise are less descriptive. Code length: Implementation methods are concise, but repetitive documentation and deprecated overloads increase reading volume. Action granularity: Statements generally perform one action per line, with a compact, understandable ternary for final completion. Reading flow: Consistent formatting and straightforward validation make execution easy to follow, though asynchronous callbacks and coordination among counters, failure state, and the aggregate promise require some cross-referencing.