Sample
int-684c351766b6-I05
Rewrite eligible decimal integer literals in hexadecimal notation
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 1 | 0–1; higher is more readable |
| Scalabrino | 0.83 | 0–1; higher is more readable |
| Dorn | 0.9 | 0–1; higher is more readable |
| Mi | 0.759 | 0–1; higher is more readable |
| LLOC | 2 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 18.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 20 | 0–20; mean of three runs |
| BTTF | 0.78 | 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. | 27 | +10.8 |
| 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.721 | −7.081 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 118.593 | −3.914 |
Intercept 8.87 + feature contributions = 8.675 (log-odds).
Score = sigmoid(8.675) = 1.
| Score | 0.83 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.021 | +0.738 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 16 | +0.47 |
| 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. | 75.893 | +0.451 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 76 | +0.422 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 12 | −0.322 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 26.87 | −0.034 |
Intercept 0.07 + feature contributions = 2.192 (log-odds).
Score = sigmoid(2.192) = 0.9.
| Score | 0.759 |
|---|
| Score | 2 |
|---|
Run 1
This code is highly readable. The structure is logical, with a clear package declaration, imports, and a single interface definition. There is no nesting, making the code flat and easy to scan. The intent is unambiguous: the interface defines a contract for Spring test context bootstrapping. The code is concise, containing only two method declarations with proper Javadoc. Each method has a single, clear purpose per line, and reading flows naturally from the interface Javadoc to the method signatures. The only minor deductions are for the absence of explicit braces and the use of generic wildcards, which could slightly reduce clarity for novice readers, but overall this is exemplary code.
Run 2
The code is highly readable. It follows a clear, logical structure with an interface definition, and each method is concise and has a single responsibility. The nesting is minimal, with no deeply nested structures. The intent is clearly documented with Javadoc for the interface and each method, including parameter and return descriptions. The code length is appropriate for the functionality, and each action is isolated on its own line. The reading flow is natural, moving from the interface documentation to method signatures and their documentation. Minor deductions only because it's a simple interface with no complex logic to showcase structural depth, but it is exemplary for what it is.
Run 3
This interface demonstrates excellent readability. The structure is logical: package declaration, import-free, a clear Javadoc class-level comment, and two well-documented methods. Nesting is non-existent (flat interface). The intent of each method is unambiguous due to precise naming and Javadoc that explains both purpose and return contract. The code is concise without being terse—no unnecessary methods or comments. Action granularity is clean, with one method declaration and one return statement per method. Reading flow follows natural Java interface conventions: type declaration, then methods grouped conceptually. Minor deduction only because interfaces are inherently simple; the example doesn't showcase more complex readability challenges.
Run 1
Code Structure: A logically organized interface contains two closely related method declarations. Nesting: No nested control flow or unnecessary hierarchy. Clarity of intent: Descriptive interface and method names, supported by precise Javadoc, clearly communicate purpose and non-null return contracts. Code length: Concise, with documentation proportionate to a public API. Action granularity: Each method declaration occupies its own line and represents a single responsibility. Reading flow: The package declaration, interface documentation, and consistently documented methods follow a natural, conventional Java layout.
Run 2
Code Structure: A logically organized interface with two related accessor methods. Nesting: No nested control flow or unnecessary structural complexity. Clarity of intent: Descriptive interface and method names, supported by precise Javadoc, clearly communicate the bootstrap context's purpose and non-null return contracts. Code length: Concise, with documentation proportionate to the small API. Action granularity: Each method declaration occupies its own line and expresses a single responsibility. Reading flow: Package declaration, interface documentation, and individually documented methods follow a natural, conventional Java layout.
Run 3
Code Structure: A clearly organized interface groups two related accessors under a well-defined abstraction. Nesting: No nested control flow; only the interface scope. Clarity of intent: Descriptive interface and method names, supported by precise Javadoc and non-null return contracts, make the purpose explicit. Code length: Minimal declarations with proportionate documentation and no unnecessary implementation. Action granularity: Each method declaration occupies its own line and expresses a single responsibility. Reading flow: Conventional Java ordering—package, interface documentation, then documented methods—provides a natural, consistent reading sequence.