Sample
int-eecf914f32e6-I12
Inline all eligible single-use intermediate local variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.584 | 0–1; higher is more readable |
| Dorn | 0.87 | 0–1; higher is more readable |
| Mi | 0.255 | 0–1; higher is more readable |
| LLOC | 42 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs |
| BTTF | 0.55 | 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. | 5135.232 | −169.463 |
| 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.868 | −7.302 |
Intercept 8.87 + feature contributions = -107.495 (log-odds).
Score = sigmoid(-107.495) = 0.
| Score | 0.584 |
|---|
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.941 | +1.7 |
| 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.895 | −0.566 |
| 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.136 |
Intercept 0.07 + feature contributions = 1.898 (log-odds).
Score = sigmoid(1.898) = 0.87.
| Score | 0.255 |
|---|
| Score | 42 |
|---|
Run 1
The code is highly readable. It has clear logical structure, separating task-wrapping methods from pure delegation methods with comments. Nesting is minimal, though the Runnable wrapper lambda contains a try/catch with a nested call, which is acceptable. Intent is explicit: subclass to wrap tasks before submission. The code is concise, avoiding unnecessary verbosity, and each line generally performs one action. Reading flow is natural, from constructor to abstract wrap methods to wrapped delegation and finally plain delegation. Naming is descriptive and consistent. Minor clarity improvements could include extracting the lambda body into a private method, but overall this is exemplary Java code.
Run 2
The code demonstrates strong readability with clear structure and logical organization. The class has a single responsibility (wrapping tasks) and methods are grouped logically: wrapping methods, then wrapped delegation methods, then plain delegation methods. Nesting is minimal—the only lambda contains a try-catch but remains flat and understandable. Intent is clearly communicated through descriptive method names, comprehensive Javadoc, and comments separating different method categories. Code length is appropriate for an abstract executor service. Action granularity is generally one action per line, with only the lambda body combining a few operations. Reading flow is natural: declaration, constructor, abstract methods, private helper, then method groups in order of complexity. Minor deductions: nullness annotations add slight visual noise, and the wrapTask lambda could be extracted for clarity, but overall this is production-quality, maintainable code that follows clean code principles well.
Run 3
The code is highly readable with clear structure: wrapping methods are grouped separately from plain delegation methods, making intent obvious. Nesting is minimal, with only one lambda body and a try-catch block. Each method performs a single action, preserving consistent granularity and natural reading flow. Naming is explicit (wrapTask, wrapTasks, delegate), and Javadoc provides helpful context. Minor deductions: the generic type bounds like <T extends @Nullable Object> add slight verbosity, and the wrapTask(Runnable) lambda could be extracted for clarity, but overall the code is concise, well-organized, and maintainable.
Run 1
Code Structure: Clearly separates task-wrapping helpers, wrapped submission methods, and lifecycle delegation. Nesting: Mostly flat, with only a simple loop and a lambda containing try/catch. Clarity of intent: Descriptive names, Javadoc, and grouping comments make the wrapper/delegate purpose explicit; generic nullness annotations add some visual complexity. Code length: Methods are concise; most repetition is necessary to implement ExecutorService. Action granularity: Statements generally perform one action per line, although nested calls combine validation, wrapping, and delegation. Reading flow: Consistent formatting and predictable method organization support easy scanning. Minor distractions include tightly packed imports, an unnecessary blank line, redundant parentheses, and the slightly less obvious deferred wrapping inside the Runnable lambda.
Run 2
Code Structure: Clearly separates wrapping helpers, task-submission methods, and lifecycle delegation. Nesting: Shallow overall, with only a loop and a lambda containing try/catch. Clarity of intent: Descriptive names, Javadoc, and section comments explain the wrapper/delegate design; generic nullness annotations and nested callable conversion add minor complexity. Code length: Most methods are concise; repetition largely follows the ExecutorService interface rather than unnecessary verbosity. Action granularity: Statements generally perform one action per line, although composed wrapping and delegation calls require unpacking multiple operations. Reading flow: Consistent formatting and logical method grouping make the class easy to scan. Minor distractions include tightly packed imports, an extra blank line, and redundant parentheses in the Runnable wrapper.
Run 3
Code Structure: Clearly separates task-wrapping helpers, submission methods, and lifecycle delegation. Nesting: Shallow overall; only the Runnable wrapper adds a lambda with try/catch. Clarity of intent: Descriptive names, focused Javadoc, and section comments make the wrapping/delegation purpose explicit. Generic nullability annotations and the nested wrapTask(callable(...)).call() expression add some cognitive overhead. Code length: Concise implementations, although required ExecutorService overloads create repetitive boilerplate. Action granularity: Statements generally perform one action per line; composed wrapping and delegation calls remain understandable. Reading flow: Consistent formatting and logical method grouping support natural top-to-bottom reading. Minor distractions include tightly packed imports, a stray blank line, and unnecessary parentheses in the Runnable wrapper.