Sample
int-13c1da3ac4c7-I08
Select one of ten high-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.995 | 0–1; higher is more readable |
| Scalabrino | 0.788 | 0–1; higher is more readable |
| Dorn | 0.661 | 0–1; higher is more readable |
| Mi | 0.23 | 0–1; higher is more readable |
| LLOC | 5 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 19 | 0–20; mean of three runs |
| BTTF | 0.559 | 0–1; higher is more readable |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Source linesThe number of non-empty source lines. | 80 | +32 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 859.051 | −28.349 |
| 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.84 | −7.26 |
Intercept 8.87 + feature contributions = 5.261 (log-odds).
Score = sigmoid(5.261) = 0.995.
| Score | 0.788 |
|---|
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. | 79 | −1.761 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 93.827 | +0.709 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 79.772 | +0.705 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.028 | +0.674 |
| 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.975 | −0.569 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 34 | +0.439 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = 0.666 (log-odds).
Score = sigmoid(0.666) = 0.661.
| Score | 0.23 |
|---|
| Score | 5 |
|---|
Run 1
The code is well-structured Java interface code with clear intent. The structure is logical, with imports grouped together and methods organized consistently. Nesting is minimal—only one level of generic type parameters and no deep conditional nesting. Clarity of intent is strong: each method's purpose is documented with Javadoc, especially the deviations from the parent interface. Code length is concise; the interface itself is short, though some Javadoc comments are repetitive, which slightly reduces readability. Action granularity is appropriate—each method declaration and annotation is on its own line. Reading flow is natural, with Javadoc summaries preceding each method. The main minor drawbacks are repetitive Javadoc blocks and long generic type declarations in the class signature, which could be visually noisy, but overall this is highly readable library code.
Run 2
This code is highly readable. The structure is logical: package declaration, imports, comprehensive Javadoc, and a clear interface definition. There is minimal nesting—only method declarations within the interface, with no deep blocks. Intent is explicit through descriptive method names and thorough documentation. The code is concise, with each method serving a clear purpose without extra length. Action granularity is appropriate: each method declaration and annotation is on its own line, aiding readability. Reading flow is natural, moving from type-level Javadoc down to method signatures with relevant explanations. Minor deductions: the repeated similar Javadoc text for get/removeAll/replaceValues is slightly verbose, but this is standard for API documentation and improves clarity.
Run 3
The code is a cleanly structured interface definition with clear intent and excellent readability. Each method is documented with Javadoc that explains behavioral specifics, and method declarations are concise and focused. The structure is logical with no deep nesting, and each action is clearly separated. Reading flow is natural, following interface conventions. Minor deductions are for some duplicated Javadoc text and a slightly long class-level Javadoc, but overall this is highly maintainable code.
Run 1
Code Structure: A well-organized interface with imports, class documentation, and consistently documented method declarations. Nesting: Flat structure with no nested control flow. Clarity of intent: Descriptive method names and precise Javadoc clearly explain duplicate values, insertion ordering, return types, and equality semantics. Code length: Declarations are concise, though repeated documentation for three methods adds some redundancy. Action granularity: Each method declaration and annotation occupies its own line; no unrelated operations are combined. Reading flow: Consistent formatting and a natural progression from value access and modification to map views and equality make the interface easy to scan. Minor drawbacks are repetitive prose and the lack of a blank line between the package declaration and imports.
Run 2
Code Structure: The interface is logically organized, with imports, interface documentation, and clearly separated method declarations. Nesting: There is no control-flow nesting; all methods sit at a single interface level. Clarity of intent: Descriptive names, precise signatures, and detailed documentation clearly explain duplicate handling, insertion ordering, return types, and equality semantics. Code length: Declarations are concise, though repeated documentation for three methods adds modest verbosity. Action granularity: Each declaration occupies its own line, with annotations separated cleanly; there are no combined operations. Reading flow: Consistent formatting and documentation placement make the interface easy to scan from general contract to individual methods. Minor drawbacks include the lack of spacing after the package declaration and some visual complexity from generic bounds and nullness annotations.
Run 3
Code Structure: The interface is logically organized, with imports, interface-level documentation, and clearly separated method declarations. Nesting: Flat structure with no nested control flow. Clarity of intent: Descriptive names, explicit return types, annotations, and detailed Javadoc clearly explain ordering, duplicates, and equality semantics. Code length: Declarations are concise, although repeated documentation about List return types adds some unnecessary length. Action granularity: Each method declaration stands alone, with annotations and documentation on separate lines; no actions are bundled together. Reading flow: Consistent formatting and documentation make the API easy to scan and understand. Minor drawbacks are repetitive comments and the lack of a blank line between the package declaration and imports.