Sample
int-a2a9f606eb01-I06
Invert eligible conditions and exchange their branches
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.916 | 0–1; higher is more readable |
| Scalabrino | 0.891 | 0–1; higher is more readable |
| Dorn | 0.825 | 0–1; higher is more readable |
| Mi | 0.508 | 0–1; higher is more readable |
| LLOC | 1 | 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.732 | 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. | 31 | +12.4 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 353.108 | −11.653 |
| 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.818 | −7.226 |
Intercept 8.87 + feature contributions = 2.391 (log-odds).
Score = sigmoid(2.391) = 0.916.
| Score | 0.891 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.026 | +0.685 |
| 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. | 77 | +0.404 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 69.906 | +0.323 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 14 | −0.253 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 32 | −0.097 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 30.718 | +0.02 |
Intercept 0.07 + feature contributions = 1.55 (log-odds).
Score = sigmoid(1.55) = 0.825.
| Score | 0.508 |
|---|
| Score | 1 |
|---|
Run 1
The code is a well-structured Spring interface with clear intent. It has minimal nesting (none), appropriate length for its purpose, and each parameter is on its own line for readability. The Javadoc provides comprehensive context about how to use the interface, including references to related classes. The package structure and imports are standard and organized. The annotation @Nullable is used consistently. The method signature is clean and logically ordered. Points deducted only because the Javadoc could be slightly more concise, and there is a minor formatting inconsistency with the parameter continuation indentation. Overall, this is exemplary interface design that follows Java conventions perfectly.
Run 2
The code is highly readable. It has a clear, logical structure with a single interface and one method. Nesting is non-existent, and the intent is well documented with a thorough JavaDoc explaining each parameter and its purpose. The code length is concise, containing only the necessary method signature and documentation. Action granularity is excellent, with each parameter on its own line for clarity. The reading flow is natural, guiding the reader through the contract's purpose before presenting the method signature. The only minor deductions are for the slightly dense JavaDoc text, though it remains clear and informative.
Run 3
The code is highly readable. Structure is logical, presenting a clean interface with clear Javadoc. Nesting is non-existent. Intent is explicit through the method name and documentation comments, which explain purpose and parameter usage. Code length is concise, containing only the essential contract. Action granularity is one action per line (method declaration with parameters). Reading flow is natural due to well-organized imports, class-level docs, and a single method with meaningful parameter names. Minor deductions: Javadoc is slightly dense and references multiple related types, which could be marginally overwhelming for quick scanning.
Run 1
Code Structure: A single, focused interface with logically grouped imports and documentation. Nesting: Minimal nesting, limited to the interface body. Clarity of intent: Descriptive names and Javadoc clearly explain the customization contract, parameters, and server-specific usage; nullable annotations clarify optional inputs. Code length: Concise, with documentation proportionate to the API's purpose. Action granularity: One method declaration, with parameters split across lines for readability and no combined actions. Reading flow: Natural progression from package and imports to interface documentation and method contract. Minor formatting improvements, such as a blank line after the package declaration, would enhance visual separation.
Run 2
Code Structure: A single, focused interface with neatly grouped imports and one method. Nesting: No nested control flow; only the interface scope. Clarity of intent: Descriptive names, comprehensive Javadoc, and explicit nullable annotations clearly communicate the configuration contract. Code length: Concise, with documentation proportionate to the API's purpose. Action granularity: One declaration, with parameters split across lines for readability; no combined actions. Reading flow: Natural progression from package and imports to interface documentation and method contract. Minor spacing improvements, such as blank lines after the package declaration and before imports from different groups, would improve visual separation.
Run 3
Code Structure: A logically organized interface with imports, interface documentation, and one method. Nesting: Minimal, with no nested control flow. Clarity of intent: Descriptive names, detailed Javadoc, and explicit nullable annotations clearly communicate the customization contract; the circumstances under which nullable parameters are absent could be clearer. Code length: Concise, with documentation proportionate to the API. Action granularity: A single method declaration, with parameters split across lines for easy scanning. Reading flow: Natural top-to-bottom progression; a blank line between the package declaration and imports would slightly improve visual separation.