Sample
int-db09d0974300-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.578 | 0–1; higher is more readable |
| Dorn | 0.87 | 0–1; higher is more readable |
| Mi | 0.244 | 0–1; higher is more readable |
| LLOC | 43 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 19 | 0–20; mean of three runs |
| BTTF | 0.483 | 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. | 5186.14 | −171.143 |
| Source linesThe number of non-empty source lines. | 151 | +60.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.87 | −7.305 |
Intercept 8.87 + feature contributions = -109.178 (log-odds).
Score = sigmoid(-109.178) = 0.
| Score | 0.578 |
|---|
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. | 152 | −4.346 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 130 | +3.759 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 150.901 | +1.699 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 96.072 | +0.746 |
| 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. | 99.914 | −0.567 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.083 | +0.138 |
Intercept 0.07 + feature contributions = 1.898 (log-odds).
Score = sigmoid(1.898) = 0.87.
| Score | 0.244 |
|---|
| Score | 43 |
|---|
Run 1
This code is highly readable. It follows a clear, logical structure: documentation comments explain the class purpose and wrapping behavior, fields are declared first, then the constructor, protected abstract/overridable methods, private helpers, and finally override methods grouped by behavior. The nesting is minimal, with only a shallow loop and a lambda. Intent is clear from method names like wrapTask, wrapTasks, and delegate. The code is concise—each method performs a single delegation or wrapping action, so action granularity is excellent. Reading flow is natural: the core wrapping logic is presented before the boilerplate delegation. The only minor drawback is the presence of type-use annotations (e.g., <T extends @Nullable Object>) and a slightly dense lambda body, which may add slight noise but are idiomatic for Guava.
Run 2
This code is highly readable due to its clear logical structure, minimal nesting, and consistent patterns. The class is organized into distinct sections: constructor, abstract wrapTask methods, the wrapTasks helper, methods that wrap before delegating, and methods that simply delegate. Nesting is shallow, appearing only in the lambda and loop, both of which are straightforward. Intent is explicit through descriptive method names and Javadoc explaining the wrapping behavior. The code is concise without sacrificing clarity—each method delegates cleanly with a single purpose. Action granularity is excellent: each line or statement performs one clear operation. Reading flow is natural, moving from setup to core wrapping logic to delegation. The only minor drawback is the repetitive delegation methods, but this is typical for wrapper classes and does not hinder understanding. Overall, it is a model of clean, maintainable code with strong separation of concerns and minimal complexity.
Run 3
The code is highly readable. It follows a clear, logical structure with distinct sections for task wrapping and delegation. Nesting is minimal, primarily limited to a single lambda and a loop. Methods clearly express intent and are concise, adhering to single-action-per-line. The reading flow is natural: high-level wrapping methods first, then simple delegation methods. Javadoc is helpful but not excessive. Minor deductions are for slightly verbose generic syntax and the multi-line generic method signatures, which slightly impact scanability.
Run 1
Code Structure: Clearly separates wrapping helpers, task-submission methods, and lifecycle delegation. Nesting: Shallow overall; only the Runnable wrapper introduces a lambda with try/catch. Clarity of intent: Descriptive names, Javadoc, and section comments make the task-wrapping purpose explicit. Code length: Appropriate for implementing ExecutorService; repeated delegation methods are necessary interface boilerplate rather than unnecessary verbosity. Action granularity: Statements generally perform one clear action, though nested wrapping and delegation calls combine steps compactly. Reading flow: Consistent formatting and predictable method grouping support natural top-to-bottom reading. Generic bounds, nullness annotations, and exception-handling utilities add minor visual and conceptual complexity.
Run 2
Code Structure: Clearly separates wrapping helpers, task-submission methods, and lifecycle delegation. Nesting: Shallow overall; only the Runnable adapter introduces a lambda with try/catch. Clarity of intent: Descriptive names, Javadoc, and section comments make the wrapping-and-delegation purpose explicit. Code length: Methods are concise; repetition largely reflects the ExecutorService interface rather than unnecessary verbosity. Action granularity: Statements generally perform one action each, though nested wrapping and delegation calls combine related operations compactly. Reading flow: Progresses naturally from construction and customization hooks to helpers, submission methods, and lifecycle methods. Minor readability costs come from dense generic/nullness annotations, long signatures, and tightly packed imports.
Run 3
Code Structure: Clearly separates wrapping helpers, task-submission methods, and lifecycle delegation. Nesting: Shallow overall; only the Runnable adapter introduces a lambda with try/catch. Clarity of intent: Descriptive names, focused Javadoc, and section comments make the wrapping-and-delegation purpose explicit. Code length: Methods are concise; repetition is largely required by the ExecutorService interface, though annotations and generic signatures add visual bulk. Action granularity: Statements generally perform one clear action, with nested wrapping calls remaining easy to understand. Reading flow: Progresses naturally from construction and customization hooks to submission and lifecycle methods. Minor readability costs come from dense imports and verbose nullness-aware type declarations.