Sample
Dorn/java/122
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.126 | 0–1; higher is more readable | 74.7Δ 14.5 |
| Scalabrino | 0.939 | 0–1; higher is more readable | 98.1Δ 8.9 |
| Dorn | 0.741 | 0–1; higher is more readable | 70.5Δ 18.7 |
| Mi | 0.479 | 0–1; higher is more readable | 50.1Δ 39.0 |
| LLOC | 7 | Logical lines; fewer is more readable | 67.7Δ 21.4 |
| DeepSeek V4 Pro | 17.67 | 0–20; mean of three runs | 97.1Δ 7.9 |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs | 80.4Δ 8.8 |
| BTTF | 0.663 | 0–1; higher is more readable | 87.7Δ 1.4 |
| Human | 3.94 | 1–5; original rating | 89.1 |
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) |
|---|---|---|
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 722.571 | −23.845 |
| Source linesThe number of non-empty source lines. | 48 | +19.2 |
| 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.109 | −6.164 |
Intercept 8.87 + feature contributions = -1.939 (log-odds).
Score = sigmoid(-1.939) = 0.126.
| Score | 0.939 |
|---|
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. | 49 | −0.699 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 36 | +0.508 |
| 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. | 74.755 | +0.499 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.049 | +0.463 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 36 | −0.405 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 71.939 | +0.356 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 47.908 | +0.26 |
Intercept 0.07 + feature contributions = 1.052 (log-odds).
Score = sigmoid(1.052) = 0.741.
| Score | 0.479 |
|---|
| Score | 7 |
|---|
Run 1
The code is highly readable with clear structure, minimal nesting, and concise methods. It follows consistent formatting, has descriptive Javadoc, and each method performs a single, focused action. The only minor deduction is for the multi-line parameter alignment in the ECNamedCurveParameterSpec constructor call, which slightly disrupts natural reading flow.
Run 2
The code is highly readable. It has a clear, logical structure with a class containing two well-defined static methods. Nesting is minimal, with only a single null-check conditional in getParameterSpec. Intent is clearly communicated through descriptive method names, Javadoc comments, and parameter/return documentation. The code is concise, avoiding unnecessary boilerplate. Action granularity is appropriate—each logical step (lookup, null check, return construction) is separated, though the constructor call spans multiple lines for readability. Reading flow is natural: lookup, validate, construct, return. One minor issue is the oddly indented multi-line constructor arguments, which slightly disrupts visual flow, but overall the code excels in clarity and maintainability.
Run 3
The code is highly readable with clear structure and intent. The class has a single, well-documented purpose: locally supported named curves. Methods are concise and each performs a single logical action. Nesting is minimal (one level), and the reading flow is natural: get parameter spec by name, then get all names. Imports are relevant and minimal. The only minor issues are a slight inconsistency in parameter alignment formatting and the lack of explicit generic type on the Enumeration return, which is acceptable given the era of the code. Overall, this is exemplary readable Java code.
Run 1
Code Structure: Two small methods cleanly separate parameter lookup from curve-name enumeration, although the class lacks a closing brace as shown. Nesting: Minimal nesting and an early null return keep control flow flat. Clarity of intent: Method names and documentation clearly describe behavior; the abbreviated variable ecP is less descriptive. Code length: Concise implementation with slightly repetitive documentation and unnecessary whitespace. Action granularity: Each statement performs a distinct action, and constructor arguments appear on separate lines. Reading flow: Lookup, availability check, and parameter construction follow a natural sequence. Inconsistent spacing and excessive constructor indentation mildly disrupt readability.
Run 2
Code Structure: Two small, logically separated methods provide curve lookup and name enumeration, though the class's closing brace is missing. Nesting: Minimal nesting and an early null return keep control flow simple. Clarity of intent: Method names and documentation explain behavior clearly, but the abbreviated variable ecP and raw Enumeration type reduce explicitness. Code length: Concise implementation with little unnecessary code, although documentation repeats some information. Action granularity: Each statement performs a single clear action; constructor arguments are individually listed. Reading flow: Lookup, availability check, and parameter construction follow a natural sequence. Uneven spacing and excessive constructor-argument indentation slightly disrupt scanning.
Run 3
Code Structure: Two focused methods provide a logical, simple organization, though the class's closing brace is missing in the supplied snippet. Nesting: Minimal nesting and an early null return keep control flow flat. Clarity of intent: Method names and documentation clearly describe curve lookup and enumeration; the abbreviated variable ecP and raw Enumeration type reduce precision slightly. Code length: Concise, with little unnecessary logic, although documentation repeats some information. Action granularity: Each statement performs one clear action, and constructor arguments are separated onto individual lines. Reading flow: Lookup, availability check, and parameter construction follow naturally. Inconsistent spacing and excessive constructor-argument indentation slightly disrupt otherwise straightforward reading.