Source code
Official dataset source · Dorn/java/118
Sample
Dorn/java/118
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.991 | 0–1; higher is more readable | 96.7Δ 63.8 |
| Scalabrino | 0.964 | 0–1; higher is more readable | 100.0Δ 67.1 |
| Dorn | 0.864 | 0–1; higher is more readable | 90.0Δ 57.1 |
| Mi | 0.581 | 0–1; higher is more readable | 61.8Δ 29.0 |
| LLOC | 2 | Logical lines; fewer is more readable | 93.7Δ 60.9 |
| DeepSeek V4 Pro | 9.67 | 0–20; mean of three runs | 39.4Δ 6.5 |
| GPT-6.1 Sol | 12.67 | 0–20; mean of three runs | 27.3Δ 5.6 |
| BTTF | 0.778 | 0–1; higher is more readable | 96.4Δ 63.5 |
| Human | 3.05 | 1–5; original rating | 32.9 |
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.36 | −6.54 |
| Source linesThe number of non-empty source lines. | 9 | +3.6 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 36 | −1.188 |
Intercept 8.87 + feature contributions = 4.742 (log-odds).
Score = sigmoid(4.742) = 0.991.
| Score | 0.964 |
|---|
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. | 57 | +1.251 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 1 | −0.703 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.026 | +0.685 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 10 | +0.682 |
| 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. | 8.966 | −0.285 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 34.3 | −0.251 |
Intercept 0.07 + feature contributions = 1.848 (log-odds).
Score = sigmoid(1.848) = 0.864.
| Score | 0.581 |
|---|
| Score | 2 |
|---|
Run 1
The code consists of two method signatures with minimal context. The indentation and formatting are inconsistent, with a tab before 'Category category );' and misaligned braces. The first method signature appears incomplete or fragmented, lacking a method name or return type. The second signature is split across multiple lines unnecessarily, reducing readability. The Javadoc comments are helpful but incomplete, especially for the first method. Code structure is unclear due to missing surrounding class or interface context. Nesting is negligible, but the overall organization feels disjointed. The intent of the methods is partially clear from comments, but the broken signature obscures purpose. Code length is reasonable, but action granularity is poor because a single method signature is unnecessarily broken across lines. Reading flow is disrupted by inconsistent indentation and incomplete syntax. While the comments provide some clarity, the code itself is not presented in a readable or coherent form.
Run 2
The code is a small snippet showing method signatures and comments, making it partially readable. It has clear intent with Javadoc comments explaining parameters, and it keeps one action per line. However, the structure is awkward: excessive indentation, odd line breaks before method names (e.g., 'public void' followed by a newline), and a trailing incomplete line ('Category category );' at the start) suggest tangled or misaligned formatting. Nesting is not an issue, and length is concise, but reading flow is disrupted by inconsistent spacing and alignment. Overall, the intent is understandable but the presentation hurts clarity.
Run 3
The code is a fragment of an interface showing method signatures. Structure is minimal but lacks surrounding context, making it appear tangled. Nesting is not applicable, but the formatting is inconsistent (misaligned braces, odd line breaks) which harms readability. Clarity of intent is moderate: the comments explain the purpose, but the first method is incomplete and disconnected. Code length is concise, but the fragment is unnecessarily broken across lines. Action granularity is fine—one action per line—but the line breaks are unnatural. Reading flow is disorganized due to the incomplete first method and inconsistent indentation. Overall, it is poorly formatted and incomplete, making it difficult to evaluate or understand fully.
Run 1
Code Structure: The documented method declaration is logically organized, but the leading dangling parameter fragment makes the snippet incomplete. Nesting: No deep nesting; indentation is inconsistent. Clarity of intent: The method name and Javadoc clearly identify a category-removal notification. Code length: Concise overall, though the declaration is unnecessarily spread across several lines. Action granularity: Only one declaration is shown, with no multiple actions per line. Reading flow: The comment-to-method progression is natural, but the opening fragment, mixed indentation, and split declaration interrupt reading.
Run 2
Code Structure: The documented method declaration is logically organized, but the initial orphaned parameter fragment makes the snippet incomplete. Nesting: No nesting, so it is easy to scan. Clarity of intent: The method name and Javadoc clearly indicate a category-removal notification. Code length: Concise overall, although splitting the declaration across several lines adds unnecessary vertical space. Action granularity: The single declaration is not mixed with other operations. Reading flow: Inconsistent indentation and the separation of the return type, method name, and parameter interrupt otherwise straightforward reading.
Run 3
Code Structure: The documented method declaration is logically organized, but the leading orphaned parameter fragment makes the snippet incomplete. Nesting: There is no nesting, so it is easy to scan. Clarity of intent: The method name and Javadoc clearly describe a category-removal notification. Code length: The snippet is concise, although splitting the declaration across several lines adds unnecessary vertical space. Action granularity: Declaration elements are separated clearly, with no multiple actions per line. Reading flow: Inconsistent indentation and the fragmented opening interrupt an otherwise straightforward reading flow.