Source code
Official dataset source · Dorn/java/134
Sample
Dorn/java/134
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 47.6Δ 39.3 |
| Dorn | 0.644 | 0–1; higher is more readable | 57.1Δ 29.8 |
| Mi | 0.575 | 0–1; higher is more readable | 60.4Δ 26.5 |
| LLOC | 1 | Logical lines; fewer is more readable | 97.9Δ 11.0 |
| DeepSeek V4 Pro | 15.33 | 0–20; mean of three runs | 79.9Δ 7.0 |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs | 80.4Δ 6.5 |
| BTTF | 0.73 | 0–1; higher is more readable | 94.7Δ 7.8 |
| Human | 3.88 | 1–5; original rating | 86.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) |
|---|---|---|
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 749.947 | −24.748 |
| Source linesThe number of non-empty source lines. | 29 | +11.6 |
| 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.939 | −7.408 |
Intercept 8.87 + feature contributions = -11.687 (log-odds).
Score = sigmoid(-11.687) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 1 | −0.703 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 82.233 | +0.522 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.056 | +0.397 |
| 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. | 87.933 | −0.059 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 30 | −0.026 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 28.966 | −0.005 |
Intercept 0.07 + feature contributions = 0.595 (log-odds).
Score = sigmoid(0.595) = 0.644.
| Score | 0.575 |
|---|
| Score | 1 |
|---|
Run 1
The code is highly readable due to its clear and logical structure. It consists solely of license information, package declaration, and organized imports, all of which are standard and predictable. There is no nesting and no executable logic, so criteria like nesting, action granularity, and reading flow are inherently well-satisfied. Intent is obvious: the file is a utility class for workflow runtime context. The length is concise and appropriate for a class with no implemented methods. One minor deduction is for the verbosity of the license header, but that is standard practice. Overall, it is clean, flat, and unambiguous.
Run 2
The code is a clean, well-structured package declaration with clear import organization. However, it is incomplete—it's just a header/import block without any actual class or method body. As such, many criteria like nesting, action granularity, and reading flow only partially apply. The structure is logical: copyright comment, package, then imports grouped by external and internal packages, which improves clarity. There is no unnecessary length or tangled nesting. The intent is reasonably clear—it prepares a utility class for Kaleo workflow runtime. However, unused imports like JSONFactoryUtil, JSONObject, Serializable, and Map suggest potential ambiguity or leftover code, which slightly hurts clarity. Overall, it is readable but not fully evaluable as a functional unit.
Run 3
The code is a license header and import block for a Java class. Structure is logical and standard: license first, package declaration, then grouped static and regular imports separated by blank lines. Nesting and action granularity are not applicable. However, clarity of intent is absent — there is no class or method body to indicate purpose. Code length is concise, and reading flow follows conventions. The score is limited because import blocks alone provide little context for evaluating actual logic readability; it reads like a clean but incomplete scaffold.
Run 1
Code Structure: The package declaration and grouped imports follow a clear, conventional Java organization. Nesting: There is no nesting, making the snippet easy to scan. Clarity of intent: Descriptive package and import names suggest workflow runtime utilities, but no implementation is present to establish the actual purpose. Code length: The snippet is short, although the lengthy license header dominates it. Action granularity: Each declaration occupies its own line; there are no combined actions. Reading flow: The progression from license to package to imports is natural, with whitespace separating dependency groups. This score applies only to the visible header and imports, not to implementation readability.
Run 2
Code Structure: The package declaration and imports are logically organized, with clear separation between project and Java imports. Nesting: No nesting is present, making the excerpt easy to scan. Clarity of intent: Descriptive package and import names suggest workflow execution utilities, but no class or executable code is shown, so the actual purpose remains incomplete. Code length: The declarations are concise; the lengthy license header adds visual overhead but serves a standard documentation purpose. Action granularity: Each declaration occupies its own line, with no combined operations. Reading flow: The conventional header-to-package-to-imports sequence is natural and consistent. This score applies only to the supplied excerpt, not to any unseen implementation.
Run 3
Code Structure: The license header, package declaration, and grouped imports follow a conventional Java layout. Nesting: There is no nesting, making the fragment easy to scan. Clarity of intent: The package and descriptive imports suggest workflow runtime utilities, but no implementation is present to establish the actual purpose. Code length: The declarations are concise; the lengthy license header is standard boilerplate rather than unnecessary logic. Action granularity: Each declaration occupies its own line, with no combined actions. Reading flow: The progression from header to package to project imports and Java imports is natural and orderly. This rating applies only to the provided fragment; method-level readability cannot be assessed.