Sample
int-1e2356dbee26-I11
Split eligible integer literals into pairs of short-named intermediate variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.001 | 0–1; higher is more readable |
| Scalabrino | 0.746 | 0–1; higher is more readable |
| Dorn | 0.714 | 0–1; higher is more readable |
| Mi | 0.351 | 0–1; higher is more readable |
| LLOC | 5 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 18 | 0–20; mean of three runs |
| GPT-6.1 Sol | 19 | 0–20; mean of three runs |
| BTTF | 0.672 | 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. | 647.078 | −21.354 |
| Source linesThe number of non-empty source lines. | 31 | +12.4 |
| 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.756 | −7.134 |
Intercept 8.87 + feature contributions = -7.217 (log-odds).
Score = sigmoid(-7.217) = 0.001.
| Score | 0.746 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 88.25 | +0.619 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| 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. | 94 | −0.316 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.07 | +0.266 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 32 | −0.097 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 20 | −0.045 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 30.832 | +0.021 |
Intercept 0.07 + feature contributions = 0.916 (log-odds).
Score = sigmoid(0.916) = 0.714.
| Score | 0.351 |
|---|
| Score | 5 |
|---|
Run 1
The code is highly readable. Structure is logical: package, imports, Javadoc, class definition, single static factory method. Nesting is minimal—only a lambda within a lambda, but both are simple. Clarity of intent is strong due to clear naming ('asynchronous', 'listener', 'executor') and comprehensive Javadoc. Code length is concise and appropriate, with no redundant boilerplate. Action granularity is mostly one action per line; the lambda bodies are compact but still understandable. Reading flow is natural: validation first, then return of the composed listener. Minor deductions: the static import is used correctly, and the inner lambda could arguably be extracted for absolute clarity, but current form is acceptable. Overall, this is exemplary Java library code.
Run 2
The code is highly readable. It has a clear, logical structure with a single purpose: providing a utility method for asynchronous removal listeners. Nesting is minimal, with only a lambda inside a lambda, which is appropriate for the task. Intent is well-documented through Javadoc and descriptive method/parameter names. The code is concise without being cryptic, and each action is separated by line breaks, maintaining one action per line. The reading flow is natural, from validation to listener creation to asynchronous execution. The only minor point is the double lambda, which might require a moment of parsing, but it is a standard pattern for wrapping callbacks in executors.
Run 3
The code is highly readable. It has clear structure with a private constructor, a single well-documented static factory method, and minimal nesting. The intent is explicit: asynchronously delegate removal notifications to an executor. The method is concise, with null checks and a lambda that performs one logical action. The reading flow is natural: validate inputs, then return a listener that executes the delegate asynchronously. Only minor deductions: the lambda chain could be slightly unclear to readers unfamiliar with functional interfaces, and there is no @return tag in Javadoc, but overall clarity is excellent.
Run 1
Code Structure: A focused utility class neatly groups a single factory method, with a private constructor preventing instantiation. Nesting: Minimal; the two nested lambdas are compact and straightforward. Clarity of intent: Descriptive names, documentation, and explicit null checks clearly communicate asynchronous listener execution. Code length: Concise, with no unnecessary implementation code. Action granularity: Each validation occupies its own line; the lambda expression naturally combines task submission with its callback. Reading flow: Documentation, signature, validation, and return follow a logical sequence. Minor drawbacks are tightly grouped package/import declarations and the nested lambda requiring slightly more attention than a simple statement.
Run 2
Code Structure: A focused utility class with a private constructor and one logically organized factory method. Nesting: Minimal; the nested lambdas are shallow and easy to follow. Clarity of intent: Descriptive names, Javadoc, and explicit null checks clearly convey asynchronous notification handling. Code length: Concise, with no unnecessary implementation detail. Action granularity: Each validation occupies its own line, and the return expression cleanly delegates execution and notification handling. Reading flow: Natural progression from documentation to validation to listener creation. Minor drawbacks are the lack of spacing between the package and imports and the modest cognitive overhead of nested lambdas.
Run 3
Code Structure: A well-organized utility class exposes one focused method and prevents instantiation. Nesting: Minimal nesting; the two lambdas clearly express asynchronous delegation. Clarity of intent: Descriptive names, documentation, and explicit null checks make the purpose clear. Code length: Concise, with no unnecessary implementation complexity. Action granularity: Each validation occupies its own line, and the return expression performs one cohesive delegation. Reading flow: Natural progression from documentation to validation to listener construction. Minor readability drawbacks are the tightly grouped package/import declarations and the nested lambda syntax, which requires some familiarity with Java.