Sample
int-995b4fca277d-I08
Select one of ten high-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.58 | 0–1; higher is more readable |
| Dorn | 0.242 | 0–1; higher is more readable |
| Mi | 0.244 | 0–1; higher is more readable |
| LLOC | 47 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 13 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.22 | 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. | 5462.963 | −180.278 |
| Source linesThe number of non-empty source lines. | 158 | +63.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.876 | −7.314 |
Intercept 8.87 + feature contributions = -115.521 (log-odds).
Score = sigmoid(-115.521) = 0.
| Score | 0.58 |
|---|
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. | 159 | −4.593 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 137 | +4.002 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 137 | −2.723 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 157.901 | +1.797 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 96.252 | +0.749 |
| 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.918 | −0.567 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.084 | +0.123 |
Intercept 0.07 + feature contributions = -1.143 (log-odds).
Score = sigmoid(-1.143) = 0.242.
| Score | 0.244 |
|---|
| Score | 47 |
|---|
Run 1
The code is generally well-structured with logical organization, flat nesting, and clear intent, but it is severely undermined by a significant flaw: a misplaced block computing factorial appears inside the invokeAny method before the return statement. This dead, unrelated code disrupts reading flow and violates single-action granularity. Other minor issues include multi-statement lambda body in wrapTask and repeated method overloads that add verbosity but are conventional for ExecutorService. The documentation and naming are clear, but the extraneous code creates ambiguity and suggests copy-paste error, greatly reducing readability. Without the dead block, it would score around 16-17; with it, the score drops due to the severe structural inconsistency and confusion it introduces.
Run 2
The code is generally readable with clear structure, low nesting, and concise methods. However, there are two issues that reduce clarity: an unrelated, dead code block (factorial calculation) is inexplicably inserted inside the invokeAny method, disrupting reading flow and intent. Additionally, the wrapTask(Runnable) method has a lambda that handles exceptions with a slightly convoluted flow, though it's still understandable. Overall, the class is well-organized with one action per line and straightforward delegation patterns.
Run 3
The code is generally well-structured with clear separation of concerns: wrapping methods first, then delegated methods. Naming is clear (wrapTask, wrapTasks) and intent is obvious for each method. The class follows a consistent pattern of wrapping then delegating. However, readability is significantly impacted by an extraneous, unrelated block of code in the invokeAny method that computes factorial but is never used - this appears to be either a copy-paste error or intentional obfuscation. This breaks reading flow and creates confusion about intent. The wrapTask(Runnable) method has a lambda with exception handling that could be extracted for clarity but is acceptable. Method overloading is handled well, and generics are used appropriately though they add some visual noise. The code is mostly flat with minimal nesting, except for the lambda and loop in the strange factorial block. Overall, the code would be highly readable if the factorial block were removed.
Run 1
Code Structure: Methods are logically grouped into wrapping and delegation sections, but an unrelated factorial block disrupts invokeAny. Nesting: Generally shallow; the Runnable wrapper uses reasonable lambda and try/catch nesting, while the factorial block adds unnecessary nesting. Clarity of intent: Descriptive names and documentation clearly explain task wrapping, but the unused factorial calculation has no apparent purpose. Code length: Most methods are concise; repeated delegation is appropriate for the interface, though the factorial block adds needless length. Action granularity: Statements generally perform one action per line; nested wrapping and delegation calls remain understandable. Reading flow: Consistent formatting, comments, and method grouping support natural reading, except for the poorly indented factorial block, which interrupts an otherwise predictable flow.
Run 2
Code Structure: Wrapping helpers, task-submission methods, and lifecycle delegation are logically grouped, but an unrelated factorial block disrupts invokeAny. Nesting: Mostly shallow; the lambda with try/catch and collection loop are easy to follow, while the factorial block adds unnecessary nesting. Clarity of intent: Descriptive names, Javadoc, and grouping comments clearly explain task wrapping and delegation; the unused factorial calculation has no apparent purpose. Code length: Most methods are concise, and repetition is justified by the ExecutorService interface, though the factorial block is needless. Action granularity: Statements generally perform one clear action per line; nested wrapping/delegation calls remain understandable. Reading flow: Consistent formatting and predictable method patterns support smooth reading, but the poorly indented factorial insertion interrupts that flow. Generic bounds and nullness annotations add some visual complexity.
Run 3
Code Structure: Clearly separates task wrapping from lifecycle delegation, but an unrelated factorial block disrupts invokeAny. Nesting: Mostly flat, with modest nesting in exception handling; the factorial block adds unnecessary depth. Clarity of intent: Descriptive names, documentation, and consistent delegation make the purpose clear, except for the unused factorial calculation. Code length: Most methods are concise; interface-driven repetition is reasonable, while the factorial code is unnecessary. Action granularity: Generally one statement per line, with straightforward wrapping-and-delegation expressions. Reading flow: Logical method grouping and comments support smooth reading, but the poorly indented factorial block abruptly interrupts the otherwise consistent flow.