Sample
int-958fa2906a2e-I07
Insert deterministic runtime-dead branches into callable bodies
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. The structure is logical, with clear package/import organization and a well-documented interface definition. Nesting is flat—there are no nested code blocks beyond normal interface declaration. The intent is explicitly conveyed through comprehensive Javadoc comments explaining method behavior and type guarantees. The code is concise, containing only essential method signatures and relevant documentation. Action granularity is appropriate: each method declaration occupies its own logical block. Reading flow is natural, moving from class-level documentation to method declarations with consistent formatting. Minor deductions could be made for some repetitive Javadoc text, but overall this exemplifies clean, maintainable API design.
Run 3
The code is a well-structured interface definition following Java conventions, with clear package organization, logical imports, and consistent formatting. The class-level Javadoc documentation is thorough and explains the purpose, contracts, and behavioral nuances clearly. Each method is documented individually, enhancing clarity of intent. Nesting is essentially flat, as this is an interface with method signatures only. Action granularity is appropriate for an interface—one declaration per method. Reading flow is natural, with documentation preceding each method in a standard order. The only minor deductions are due to slightly verbose Javadoc repetition across similar methods and the inherent length of formal documentation for an API, but this is typical for Guava library code and aids rather than hinders readability.
Run 1
Code Structure: A 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 Javadocs clearly explain duplicate values, insertion ordering, return types, and equality semantics. Code length: Declarations are concise, though repeated documentation across three methods adds some redundancy. Action granularity: Each method declaration and annotation occupies its own line, making individual elements easy to identify. Reading flow: Consistent formatting and documentation immediately preceding each method support natural top-to-bottom reading; generic types and nullness annotations add minor visual complexity.
Run 2
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, precise types, and thorough documentation explain duplicate handling, insertion order, return types, and equality semantics. Nullness annotations clarify contracts, though they add slight visual complexity. Code length: Declarations are concise, but repeated documentation across three methods adds some unnecessary length. Action granularity: Each method declaration occupies its own line, with annotations and documentation cleanly separated; there are no combined actions. Reading flow: Consistent formatting and documentation-before-declaration ordering make the interface easy to scan. The lack of blank lines separating the package declaration and import groups slightly reduces visual organization.
Run 3
Code Structure: The interface is logically organized, with imports, type documentation, and clearly separated method declarations. Nesting: The code is flat, with no nested control flow. Clarity of intent: Descriptive method names, generic types, annotations, and detailed documentation clearly explain list-valued multimap behavior and equality semantics. Code length: Declarations are concise, although repeated documentation about duplicates and insertion order adds some unnecessary length. Action granularity: Each method declaration stands alone, and annotations occupy separate lines; there are no combined actions. Reading flow: Consistent formatting and documentation immediately preceding each method make the interface easy to scan. Minor distractions include dense type annotations and repeated prose, but overall readability is excellent.