Sample
Dorn/java/216
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.986 | 0–1; higher is more readable | 95.0Δ 4.2 |
| Scalabrino | 0.948 | 0–1; higher is more readable | 98.8Δ 0.3 |
| Dorn | 0.877 | 0–1; higher is more readable | 91.6Δ 7.5 |
| Mi | 0.661 | 0–1; higher is more readable | 74.7Δ 24.5 |
| LLOC | 3 | Logical lines; fewer is more readable | 88.6Δ 10.6 |
| DeepSeek V4 Pro | 16.33 | 0–20; mean of three runs | 87.9Δ 11.3 |
| GPT-6.1 Sol | 16.67 | 0–20; mean of three runs | 73.8Δ 25.3 |
| BTTF | 0.628 | 0–1; higher is more readable | 80.5Δ 18.7 |
| Human | 4.24 | 1–5; original rating | 99.2 |
Views
Select the downloaded ZIP or its extracted folder. Files stay in your browser.
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Source linesThe number of non-empty source lines. | 29 | +11.6 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 271.029 | −8.944 |
| 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.826 | −7.238 |
Intercept 8.87 + feature contributions = 4.288 (log-odds).
Score = sigmoid(4.288) = 0.986.
| Score | 0.948 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.038 | +0.576 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 80.233 | +0.49 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 16 | +0.47 |
| 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. | 16 | −0.184 |
| 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. | 82.933 | +0.152 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 28.821 | −0.007 |
Intercept 0.07 + feature contributions = 1.965 (log-odds).
Score = sigmoid(1.965) = 0.877.
| Score | 0.661 |
|---|
| Score | 3 |
|---|
Run 1
The code is well-structured and readable. It has a clear package declaration, imports only what is needed, and defines a simple interface with three methods. The nesting is flat, and the intent of each method is clear from its name and Javadoc comments. The comments are concise and informative, explaining the parameters and return values. The code length is minimal and appropriate for the task. Action granularity is fine—each method declaration is on its own line, and the return type and parameter list are easy to scan. The reading flow is natural, moving from package to imports to the interface definition and its methods. Minor deductions: the Javadoc for getStatistics is slightly redundant with the interface-level comment, and the interface-level comment could be clearer without the self-reference. Overall, highly readable.
Run 2
The code is well-structured and readable. It defines a clear interface with three methods, each serving a distinct purpose. The Javadoc comments adequately explain the contract, especially for getStatistics and getUnit. The overall organization is logical, with imports and package declaration at the top. Nesting is non-existent, contributing to flat, easy-to-follow code. The intent of each method is clear: retrieve statistics, provide a name, and specify units. Code length is concise; no unnecessary lines or complexity. Action granularity is appropriate—each method declaration is on its own line. The reading flow is natural: package, imports, then interface definition with methods ordered logically. Minor deductions include the lack of generic types on the Map return value (raw type) and missing @return Javadoc for getName(), which slightly reduces clarity. Overall, this is a clean, maintainable interface definition.
Run 3
The code is an interface with a clear purpose: defining a statistics provider. Structure is logical—method signatures are separated by blank lines, and Javadoc explains key methods. Nesting is nonexistent, and intent is mostly clear from method names and comments. However, the getStatistics method lacks generic typing (Map instead of Map<String, ?>), and the undeclared exception behavior is ambiguous. Some documentation is sparse (getName has no comment), and the class-level Javadoc is minimal. Overall, readable but could be improved with generics and consistent documentation.
Run 1
Code Structure: The interface logically groups three related statistics-provider methods, but the missing closing brace makes the snippet incomplete. Nesting: No nested logic, so it is easy to scan. Clarity of intent: Method names and Javadoc communicate the purpose well, though the raw Map leaves key and value types unspecified, and getName lacks documentation. Code length: Short and appropriately concise, with minor redundant interface modifiers and comments. Action granularity: Each method declaration occupies its own line. Reading flow: Package, imports, interface documentation, and method declarations follow a natural order; uneven whitespace and inconsistent documentation slightly reduce polish.
Run 2
Code Structure: The interface logically groups three related statistics-provider methods, but the missing closing brace makes the snippet incomplete. Nesting: No nested logic, so it is easy to scan. Clarity of intent: Method names and documentation communicate the purpose well, although the raw Map return type leaves key and value types unspecified, and getName lacks documentation. Code length: Short and focused, with minor unnecessary whitespace and redundant public modifiers. Action granularity: Each method declaration occupies its own line. Reading flow: Package, imports, interface documentation, and method declarations follow a natural Java layout; uneven spacing and inconsistent documentation slightly reduce polish.
Run 3
Code Structure: The interface logically groups three statistics-provider methods, but the missing closing brace makes the snippet incomplete. Nesting: There is no nested logic, so it is easy to scan. Clarity of intent: Method names and documentation communicate the purpose, though the raw Map leaves key and value types unspecified, and getName lacks documentation. Code length: The interface is concise, with minor redundancy in comments and explicit public modifiers. Action granularity: Each method declaration occupies its own line. Reading flow: Package, imports, interface documentation, and methods follow a natural Java ordering, although inconsistent whitespace and uneven documentation slightly interrupt the flow.