Sample
int-8e6b62b41411-I05
Rewrite eligible decimal integer literals in hexadecimal notation
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 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18.33 | 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. It has clear logical organization, with wrapping methods grouped before pure delegation methods. Nesting is minimal—only a brief lambda in wrapTask. Intent is explicit through class and method Javadoc, naming, and structure. Action granularity is mostly one action per line, especially in delegation methods. Reading flow is natural: constructor, abstract template methods, private helper, then ExecutorService methods. Potential mild drawbacks include the long list of imports and repeated generic type declarations, but these are justified by the framework's API.
Run 3
The code is very readable. Structure is logical: class-level delegate, abstract wrapTask, helper wrapTasks, then methods are grouped by wrapping-before-delegating versus simple delegation. Nesting is shallow—only one small lambda with a try-catch. Intent is clear from descriptive method names and Javadoc, clarifying that wrapping occurs even if not executed. Length is appropriately concise; no redundant code. Each method performs one action (delegate call with wrapping where needed) and generally fits on one line. Reading flow is natural: core abstraction first, helpers, then methods in logical groups, then boilerplate delegation. Minor decreases from generics/annotations adding slight noise, but overall highly readable.
Run 1
Code Structure: Well organized into wrapping helpers, task-submission methods, and lifecycle delegation, with clear section comments. Nesting: Shallow overall; only the Runnable adapter introduces a lambda containing try/catch. Clarity of intent: Descriptive names and focused Javadoc clearly explain the wrapping-and-delegation design; generic nullness annotations add some visual complexity. Code length: Methods are concise, and most repetition is required by the ExecutorService interface. Action granularity: Statements generally perform one action per line, though nested calls combine validation, wrapping, and delegation. Reading flow: Consistent formatting and method grouping make the class easy to follow, with minor friction from lengthy generic signatures and annotations.
Run 2
Code Structure: Logically separates task-wrapping helpers, submission methods, and lifecycle delegation. Nesting: Mostly flat, with only a simple loop and a lambda containing try/catch. Clarity of intent: Descriptive names, focused Javadocs, and grouping comments clearly explain the wrapper/delegate design. Code length: Appropriate for implementing ExecutorService; repetitive forwarding methods are necessary rather than excessive. Action granularity: Statements generally perform one clear action; nested wrapping and delegation calls remain easy to understand. Reading flow: Moves naturally from construction and customization hooks to helpers, task submission, and lifecycle operations. Minor readability costs come from dense generic/nullability annotations, long method signatures, and imports without visual grouping.
Run 3
Code Structure: Well organized into wrapping helpers, task-submission methods, and lifecycle delegation, with clear section comments. Nesting: Shallow overall; only the Runnable wrapper introduces a lambda with try/catch. Clarity of intent: Descriptive names and focused Javadoc clearly explain task wrapping and delegation, although nullability annotations and generic signatures add visual complexity. Code length: Most methods are concise; repetitive forwarding is appropriate for implementing ExecutorService rather than unnecessary verbosity. Action granularity: Statements generally perform one action per line, though nested wrapping and delegation calls combine closely related operations. Reading flow: Natural progression from construction and customization hooks to wrapping operations and lifecycle methods. Minor drawbacks include densely packed imports and verbose annotated signatures, but readability remains high.