Sample
int-2ad4fc87c293-I09
Select one of ten low-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.553 | 0–1; higher is more readable |
| Dorn | 0.252 | 0–1; higher is more readable |
| Mi | 0.244 | 0–1; higher is more readable |
| LLOC | 45 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 14 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.094 | 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. | 5452.691 | −179.939 |
| Source linesThe number of non-empty source lines. | 153 | +61.2 |
| 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.925 | −7.387 |
Intercept 8.87 + feature contributions = -117.256 (log-odds).
Score = sigmoid(-117.256) = 0.
| Score | 0.553 |
|---|
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. | 154 | −4.416 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 132 | +3.829 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 132 | −2.608 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 152.921 | +1.728 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 96.747 | +0.757 |
| 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.942 | −0.568 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.085 | +0.119 |
Intercept 0.07 + feature contributions = -1.091 (log-odds).
Score = sigmoid(-1.091) = 0.252.
| Score | 0.244 |
|---|
| Score | 45 |
|---|
Run 1
The code has a clear purpose and uses a consistent delegation pattern, but suffers from several readability issues. Structure is mostly logical: constructor, abstract wrap methods, helper, then overrides. However, there is an unexplained line of obfuscated code inside submit(Runnable): `{boolean lI0O_a4e1bf68=((0x90F9^0x90F9)!=0);lI0O_a4e1bf68=!(!lI0O_a4e1bf68);}` which is pure noise and harms clarity. Nesting is flat, which is good. But action granularity suffers because many overrides simply call delegate methods, making them repetitive. Reading flow is interrupted by excessive annotations and generics on nearly every method. The code is longer than necessary for a simple wrapper. Without the obfuscated line, score would be significantly higher.
Run 2
The code is generally well-structured and readable. It uses clear method names, concise delegation, and logical ordering (wrapping methods first, then plain delegation). Nesting is minimal, and most methods are one line. However, there is a notable issue: the injected obfuscated boolean line in `submit(Runnable)` creates a jarring distraction, reduces clarity, and appears to be dead code or a test artifact. Excluding that, the code follows clean patterns with consistent formatting and clear intent.
Run 3
The code is well-structured, with clear separation between task-wrapping methods and simple delegation methods. The class has a single responsibility and uses final methods to enforce the wrapping pattern. Nesting is minimal, and intent is clearly expressed through method names and Javadoc. However, readability is significantly reduced by the injected obfuscated boolean variable inside submit(Runnable task), which is irrelevant and confusing. It adds unnecessary length and breaks the reading flow. Additionally, the wrapTask(Runnable) method catches Exception and wraps it in RuntimeException, which is not immediately obvious without reading the implementation. The use of generic type bounds like <T extends @Nullable Object> is verbose but idiomatic for this codebase. Overall, the code is highly maintainable and follows clean code practices, except for the suspicious injected line which appears to be dead code and should be removed.
Run 1
Code Structure: Logically organized into wrapping helpers, wrapping delegation methods, and lifecycle delegation methods, with useful documentation. Nesting: Mostly flat; the lambda's try/catch and collection loop are shallow and easy to follow. Clarity of intent: Descriptive names and Javadoc clearly explain task wrapping, but the unused boolean block in submit(Runnable) has an opaque name and pointless bitwise and negation operations. Code length: Most methods are concise; repeated delegation is appropriate for implementing ExecutorService, though the boolean block adds unnecessary code. Action granularity: Generally one statement per line, except the injected block compresses declaration and reassignment onto one line. Reading flow: Consistent method formatting and grouping provide a natural progression, interrupted by the unindented, irrelevant boolean block.
Run 2
Code Structure: Logically separates task-wrapping helpers, submission methods, and lifecycle delegation. Nesting: Mostly flat, with modest nesting in the lambda's try/catch and collection loop. Clarity of intent: Descriptive names and documentation clearly explain the wrapper pattern, but the unused boolean block in submit(Runnable) is cryptic and purposeless. Code length: Most methods are concise; repeated delegation is justified by the interface, while the boolean block adds unnecessary code. Action granularity: Generally one action per line, except the compressed boolean block combines declaration, bitwise computation, and reassignment. Reading flow: Consistent formatting and method grouping make the class easy to scan, but the unindented, obfuscated block abruptly disrupts that flow.
Run 3
Code Structure: Well organized into task-wrapping helpers, submission methods, and lifecycle delegation, with useful documentation. Nesting: Mostly flat; the lambda's try/catch and collection loop are shallow and manageable. Clarity of intent: Descriptive names and consistent delegation make the purpose clear, but the unused boolean block in submit(Runnable) introduces unexplained, obfuscated noise. Code length: Most methods are concise; repetition largely follows the ExecutorService interface rather than unnecessary implementation complexity. Action granularity: Generally one action per line, except the injected block, which compresses a declaration and reassignment onto one poorly formatted line. Reading flow: Logical grouping and consistent formatting support easy scanning, but the injected block abruptly disrupts that flow. Generic bounds and annotations add modest visual complexity.