Sample
int-56f46448fd54-I06
Invert eligible conditions and exchange their branches
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 | 18.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18.67 | 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
The code is highly readable due to its clear structure and organization. It follows a logical layout with distinct sections for wrapped and delegated methods, making intent immediately apparent. Nesting is minimal—only a single loop and a small lambda—and action granularity is excellent, with one operation per line. Names are descriptive and consistent. The main tradeoff is some verbose generic nullness annotations, but these are idiomatic for the codebase and do not significantly hinder comprehension.
Run 3
The code is highly readable with clear structure and intent. It follows a consistent pattern: wrapping methods are grouped separately from pure delegation methods, with explicit comments marking each section. Nesting is minimal—only a lambda and a try-catch in the Runnable wrapper. Each method performs a single, clear action, and the naming (wrapTask, wrapTasks, delegate) makes intent obvious. Generics are used appropriately without excessive complexity. The class is concise for what it does, avoiding unnecessary abstraction. Javadoc is helpful but not verbose. Minor deductions: the lambda in wrapTask(Runnable) packs exception handling into one block, slightly reducing granularity, and the repeated generic <T extends @Nullable Object> signatures add some visual noise. Overall, an excellent example of clean delegation code.
Run 1
Code Structure: Well organized into construction, wrapping helpers, wrapping delegation, and direct delegation, with clear section comments. Nesting: Shallow overall; only the Runnable adapter introduces a lambda with try/catch. Clarity of intent: Descriptive names and focused Javadoc clearly explain task wrapping and delegation. Code length: Concise implementations; repeated methods are justified by the ExecutorService interface. Action granularity: Statements generally perform one action per line, although nested wrapping and delegation calls combine related operations. Reading flow: Helpers precede their consumers, and consistent formatting makes overloads easy to scan. Minor readability costs come from verbose generic nullness annotations, dense imports, and the exception-handling adapter.
Run 2
Code Structure: Logically separates task-wrapping helpers, wrapped execution methods, and lifecycle delegation. Nesting: Mostly flat; only the Runnable adapter introduces modest lambda and try/catch nesting. Clarity of intent: Descriptive names, focused Javadoc, and section comments clearly explain the wrapping-and-delegation purpose. Code length: Methods are concise; repeated overrides add length but are appropriate for implementing ExecutorService. Action granularity: Statements generally perform one clear action per line, though nested calls combine validation, wrapping, and submission. Reading flow: Consistent formatting and method grouping make the class easy to follow. Generic bounds, nullness annotations, and long signatures slightly increase visual complexity, while tightly packed imports offer less separation.
Run 3
Code Structure: Clearly separates task-wrapping helpers, submission methods, and lifecycle delegation. Nesting: Mostly flat, with only a short loop and a lambda containing try/catch. Clarity of intent: Descriptive names, Javadoc, and grouping comments make the wrapper's purpose explicit; generic nullness annotations add minor visual complexity. Code length: Appropriate for implementing ExecutorService, though required overloads introduce repetitive boilerplate. Action granularity: Statements generally perform one clear action; nested wrapping and delegation calls remain compact and understandable. Reading flow: Progresses naturally from construction and wrapping logic to execution methods and lifecycle operations. Consistent formatting and small methods support easy scanning, with dense signatures and tightly packed imports being minor readability drawbacks.