Sample
int-475b91397d72-I06
Invert eligible conditions and exchange their branches
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 | 18 | 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. It has clear logical structure as a focused interface extending Multimap, with well-organized imports and Javadoc. Nesting is minimal—there is no deep nesting. The intent of each method is clearly documented, especially the deviations from Multimap contracts regarding List return types and ordering semantics. Code length is appropriate, with minimal boilerplate and well-placed annotations. Action granularity is clean: method signatures are concise and single-purpose. Reading flow is natural, moving from class-level documentation to method overrides with consistent formatting. The only minor deductions are for some repetition in Javadoc and the slightly verbose package-level import style, but these are negligible.
Run 3
This code is highly readable. The interface is well-structured, with clear separation between imports, Javadoc, and method declarations. Nesting is minimal. Each method's intent is clear—especially due to concise Javadoc explaining why List is returned instead of Collection. Code length is appropriate for an API contract; no unnecessary verbosity. Each annotation and method signature is cleanly separated, with one logical action per line. Reading flow is natural: documentation precedes each method, and naming follows Java conventions. Minor deductions: method signatures with generic bounds and annotations are slightly dense, but this is typical for Guava and not a readability flaw.
Run 1
Code Structure: A well-organized interface with consistent imports, annotations, and method documentation. Nesting: Flat declarations with no nested control flow. Clarity of intent: Descriptive method names and thorough Javadoc clearly explain duplicate values, insertion ordering, return types, and equality semantics. Code length: Declarations are concise, although the identical explanation repeated across three methods adds verbosity. Action granularity: Each method declaration and annotation occupies its own line, with no combined actions. Reading flow: The interface progresses naturally from its overall contract to individual operations and equality behavior. Minor distractions include dense nullness annotations, wrapped documentation links, and the lack of blank lines separating the package and imports.
Run 2
Code Structure: The interface is logically organized, with imports, type documentation, and related method declarations clearly separated. Nesting: There is only a single interface scope and no nested control flow. Clarity of intent: Descriptive names, explicit return types, annotations, and detailed documentation clearly communicate ordering, duplicate handling, and equality semantics. Code length: Declarations are concise, although repeated documentation for three methods adds some redundancy. Action granularity: Each method declaration occupies its own line, with annotations separately presented; there are no bundled operations. Reading flow: Consistent formatting and documentation immediately preceding each method make the interface easy to scan. Minor distractions include dense generic annotations and the lack of blank lines separating the package declaration and import groups.
Run 3
Code Structure: Logically organized interface with consistent imports, annotations, and method documentation. Nesting: Flat declarations with no nested control flow. Clarity of intent: Descriptive method names and detailed Javadoc clearly explain duplicate values, insertion ordering, return types, and equality semantics; nullness annotations clarify contracts. Code length: Method declarations are concise, although repeated Javadoc across three methods adds some unnecessary length. Action granularity: Each method declaration occupies its own line, with annotations cleanly separated; there are no compound statements. Reading flow: Consistent formatting and documentation preceding each method make the interface easy to scan. Minor drawbacks are repetitive documentation and the lack of a blank line between the package declaration and imports.