Sample
Dorn/java/195
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.92 | 0–1; higher is more readable | 89.4Δ 51.3 |
| Scalabrino | 0.747 | 0–1; higher is more readable | 82.6Δ 44.4 |
| Dorn | 0.859 | 0–1; higher is more readable | 87.7Δ 49.6 |
| Mi | 0.598 | 0–1; higher is more readable | 63.0Δ 24.8 |
| LLOC | 3 | Logical lines; fewer is more readable | 88.6Δ 50.4 |
| DeepSeek V4 Pro | 6.33 | 0–20; mean of three runs | 18.1Δ 20.1 |
| GPT-6.1 Sol | 15.33 | 0–20; mean of three runs | 58.6Δ 20.5 |
| BTTF | 0.755 | 0–1; higher is more readable | 95.5Δ 57.4 |
| Human | 3.13 | 1–5; original rating | 38.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) |
|---|---|---|
| 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.542 | −6.813 |
| Source linesThe number of non-empty source lines. | 10 | +4 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 109.393 | −3.61 |
Intercept 8.87 + feature contributions = 2.447 (log-odds).
Score = sigmoid(2.447) = 0.92.
| Score | 0.747 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| 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. | 48.818 | +1.598 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 11 | +0.647 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.034 | +0.608 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 9 | −0.426 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 9.3 | −0.28 |
Intercept 0.07 + feature contributions = 1.81 (log-odds).
Score = sigmoid(1.81) = 0.859.
| Score | 0.598 |
|---|
| Score | 3 |
|---|
Run 1
The code snippet is incomplete and lacks surrounding context, making it difficult to assess its full structure and intent. However, based on the visible portion, there are some readability concerns. The indentation appears inconsistent (the first parameter is indented too far), which disrupts natural reading flow. The snippet consists only of method declarations, so nesting and action granularity are not applicable. The naming is clear and follows standard Java conventions, but the incomplete nature makes it hard to infer the purpose or relationship between methods. Code length is concise, but the lack of context and inconsistent formatting significantly hinder readability. Overall, the code is readable in isolation but would benefit from proper formatting and contextual clarity.
Run 2
This code is a fragment of an interface, showing only method signatures with inconsistent indentation, making it difficult to evaluate full context. The structure is minimal but the leading tabs break standard formatting and hurt readability. Nesting is flat, which is good. Clarity of intent is low because method names like 'getUrlTitle' are ambiguous without documentation, and the purpose of the interface's role is unclear. Code length is concise, but the fragment lacks surrounding context (interface declaration, imports) needed for full understanding. Action granularity is reasonable, with each signature on its own lines. Reading flow is disrupted by the initial misalignment and the incomplete view of the code. Overall, the snippet appears to be part of a larger, probably well-organized interface, but on its own it is not highly readable due to formatting issues and missing context.
Run 3
The code is a small fragment, likely an interface excerpt, with some structural issues. It shows only two method signatures and a getter, which makes evaluating full readability difficult. The methods are clearly separated and each signature is relatively flat, but the indentation is inconsistent, making the reading flow unnatural. The intent of the methods (URL export and title retrieval) is fairly clear, but the overall context is missing. The code length is concise, but multiple actions are not present. The main deduction is due to poor formatting and lack of context, which hampers clarity.
Run 1
Code Structure: Method declarations are consistently organized, but the snippet begins with an incomplete declaration, reducing context. Nesting: No nested logic makes it easy to scan. Clarity of intent: Descriptive parameter names and return types clarify the API, though getURLExport is awkwardly named and the broad Exception provides little detail. Code length: Concise, with reasonable line wrapping. Action granularity: Each declaration and parameter occupies a distinct, readable line. Reading flow: Blank lines separate methods naturally, but the truncated opening and inconsistent URL/Url capitalization slightly disrupt readability.
Run 2
Code Structure: Method declarations are consistently formatted and separated, but the snippet begins with an incomplete declaration, limiting context. Nesting: No nested logic, making it easy to scan. Clarity of intent: getURLExport and getUrlTitle suggest their purposes, though the URL capitalization is inconsistent and the first method name is missing. Code length: Concise, with reasonable line breaks for long signatures. Action granularity: Each declaration is distinct, and parameters appear on separate lines. Reading flow: Mostly natural and orderly, disrupted primarily by the truncated opening.
Run 3
Code Structure: Interface-style method declarations are logically separated, but the fragment begins mid-declaration, reducing context. Nesting: No nested logic, making it easy to scan. Clarity of intent: getURLExport and getUrlTitle suggest their purposes, and parameter names clearly identify request and response objects; inconsistent URL capitalization slightly weakens clarity. Code length: Concise, with appropriate wrapping for long signatures. Action granularity: Each declaration is distinct, with parameters on separate lines. Reading flow: Blank lines and consistent indentation support readability, though the incomplete opening and broadly declared Exception interrupt understanding.