Sample
int-ffea6c6df720-I02
Shorten method, parameter, and local names without collisions
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.835 | 0–1; higher is more readable |
| Dorn | 0.664 | 0–1; higher is more readable |
| Mi | 0.084 | 0–1; higher is more readable |
| LLOC | 50 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 5 | 0–20; mean of three runs |
| GPT-6.1 Sol | 13.33 | 0–20; mean of three runs |
| BTTF | 0.53 | 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. | 3108.102 | −102.567 |
| 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.574 | −6.862 |
Intercept 8.87 + feature contributions = -35.759 (log-odds).
Score = sigmoid(-35.759) = 0.
| Score | 0.835 |
|---|
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.893 | +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.963 | −1.416 |
| 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.047 | +0.487 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = 0.683 (log-odds).
Score = sigmoid(0.683) = 0.664.
| Score | 0.084 |
|---|
| Score | 50 |
|---|
Run 1
The code has several readability issues. The class has a clear purpose documented in comments, but the implementation undermines this clarity. Method names are cryptic: 'add2', 'fin', 'try2', 'check', 'check2' - these do not convey intent. Variable names like 'fut', 'fut2', 'fut3', 'fut4', 'fut5' are ambiguous and progressively numbered rather than descriptively named. The listener's operation() method has an extra unnecessary nesting layer with operation2(), and action granularity is poor - multiple operations are crammed into single lines (e.g., ++doneCount; if condition; etc.). The code structure mixes concerns: field declarations are split by method definitions, and the anonymous inner class appears before the constructor. There's redundant code like the deprecated add(Promise) just casting to add(Future). The 'fin' method name is abbreviated strangely. Overall, while the documentation is thorough, the code itself requires significant effort to understand control flow and intent.
Run 2
The code is poorly readable due to confusing naming conventions (e.g., `add2`, `try2`, `fin`, `fut3`, `fut4`, `fut5`, `check`, `check2`), inconsistent method names, and unclear control flow. The listener logic is split between `operation` and `operation2`, creating unnecessary indirection. Field declarations are intermixed with methods in a non-logical order, and there is no clear separation of concerns. While the class has a useful Javadoc and the core logic is short, the naming and structure make intent hard to follow. Nesting is low, but action granularity and reading flow suffer from inconsistent naming and deprecated overloads with raw types. Overall, the code requires significant effort to understand and would benefit from clear, descriptive names and better organization.
Run 3
The code shows poor readability due to several structural and semantic problems. While the class-level Javadoc is thorough, the actual implementation is confusing: method names are misleading ('add2' should be 'addAll', 'fin' should be 'finish', 'try2' is vague, 'check'/'check2' are unclear), parameter names are meaningless ('fut3', 'fut4', 'pro2'), and the listener's logic is needlessly fragmented into 'operation' and 'operation2'. The code mixes actions per line, contains redundant event-loop checks, and has unnaturally ordered fields and methods. The deprecation annotations add noise without clarity. The nested anonymous classes increase cognitive load, and error handling is spread across multiple helper methods. Though the code is functional, its naming, structure, and flow make it hard to follow and maintain.
Run 1
Code Structure: Fields, constructors, public methods, and validation helpers are logically organized, with completion handling separated from registration. Nesting: Most methods are flat, but the listener containing an anonymous Runnable creates a moderately nested section. Clarity of intent: Descriptive state fields and extensive documentation explain the aggregation behavior, but names such as check2, try2, operation2, fin, and fut3 obscure individual responsibilities. Documentation references addAll and finish although the implemented methods are add2 and fin, making navigation confusing. Code length: Implementation methods are concise; repeated documentation and deprecated overloads increase reading overhead. Action granularity: Statements generally perform one action per line, making state changes easy to identify. Reading flow: Registration, completion counting, and aggregate notification form a coherent lifecycle, but generic helper names and mismatched documentation force readers to jump between methods to understand details.
Run 2
Code Structure: Responsibilities are logically divided among registration, completion tracking, validation, and aggregate notification methods. Nesting: Most methods are shallow, although the anonymous listener containing an anonymous Runnable adds visual complexity. Clarity of intent: Class documentation and descriptive state fields explain the purpose, but names such as operation2, try2, check2, fin, and fut3 obscure individual responsibilities. Documentation references addAll and finish even though the actual methods are add2 and fin, further confusing readers. Code length: Methods are concise, but repetitive documentation and deprecated overloads lengthen the class. Action granularity: Statements generally perform one action per line, making updates and checks easy to follow. Reading flow: Registration and completion logic are reasonably organized, but understanding asynchronous behavior requires jumping between the listener and several vaguely named helpers.
Run 3
Code Structure: Responsibilities are reasonably separated into listener handling, adding futures, finalization, and validation helpers. Nesting: Most methods are shallow, although the anonymous listener and nested Runnable create a more deeply indented section. Clarity of intent: Class documentation and descriptive state fields explain the purpose, but names such as operation2, try2, check2, fin, and fut3 obscure individual actions. Documentation references addAll and finish, while implementations are named add2 and fin; several parameter tags also mismatch actual names. Code length: Method bodies are concise, but extensive repetitive documentation and deprecated overloads increase reading effort. Action granularity: Statements generally perform one action per line, making state changes easy to identify. Reading flow: Formatting and method grouping are consistent, but understanding lifecycle checks and completion requires jumping between ambiguously named helpers and callback code.