Sample
Dorn/java/125
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.005 | 0–1; higher is more readable | 66.0Δ 8.9 |
| Scalabrino | 0.615 | 0–1; higher is more readable | 61.6Δ 13.3 |
| Dorn | 0.82 | 0–1; higher is more readable | 79.9Δ 5.0 |
| Mi | 0.724 | 0–1; higher is more readable | 88.9Δ 13.9 |
| LLOC | 9 | Logical lines; fewer is more readable | 61.3Δ 13.6 |
| DeepSeek V4 Pro | 18 | 0–20; mean of three runs | 98.3Δ 23.4 |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs | 80.4Δ 5.4 |
| BTTF | 0.577 | 0–1; higher is more readable | 68.0Δ 7.0 |
| Human | 3.66 | 1–5; original rating | 74.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. | 805.415 | −26.579 |
| Source linesThe number of non-empty source lines. | 50 | +20 |
| Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value. | 5.043 | −7.565 |
Intercept 8.87 + feature contributions = -5.273 (log-odds).
Score = sigmoid(-5.273) = 0.005.
| Score | 0.615 |
|---|
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. | 51 | −0.769 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 36 | +0.508 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.047 | +0.486 |
| 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. | 49.815 | +0.286 |
| 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. | 79.961 | +0.278 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 65.863 | +0.258 |
Intercept 0.07 + feature contributions = 1.516 (log-odds).
Score = sigmoid(1.516) = 0.82.
| Score | 0.724 |
|---|
| Score | 9 |
|---|
Run 1
The code is well-structured with a clear package declaration, imports, and a logical class hierarchy. The class extends BaseMethodImpl, inheriting common functionality while keeping this file focused. Nesting is minimal, with only one method containing a slightly deeper level due to the throws clause and list handling. Intent is clear—each method name accurately describes its purpose, and the copyright documentation adds context without cluttering the logic. Code length is concise; the class does not contain redundant or unnecessarily verbose operations. Action granularity is appropriate: one logical action per line, such as retrieving storage and adding the document tree to the list. Reading flow is natural—fields, constructor-free class, then public methods, then protected implementation. The only minor deductions stem from the slightly less obvious role of getElements in the broader hierarchy, but this is acceptable in the context of the template method pattern. Overall, the code is highly readable and maintainable.
Run 2
The code demonstrates excellent readability. It follows a logical package/import structure, uses a single class with a clear hierarchy, and maintains flat nesting with only one level of indentation in the override method. Variable and method names are descriptive ('getRootPath', '_METHOD_NAME'), and each line generally performs one clear action. The Javadoc header and @author tag add context. The minor duplication in the getElements method is negligible; overall, the code is clean, concise, and easy to understand. Only a slight improvement could come from extracting the repeated storage retrieval logic into a helper, but as written it is highly readable.
Run 3
The code is highly readable. Structure is logical: package, imports, class declaration, and clear method separation. Nesting is minimal, with only one override method containing a try/catch-like throws clause. Intent is clear—class name and method names (getMethodName, getRootPath, getElements) accurately describe behavior. Code length is appropriate; no unnecessary verbosity. Action granularity is strong: most lines perform a single operation (e.g., retrieving storage, adding elements). Reading flow is natural, following a top-to-bottom progression from method name retrieval to parameter extraction to element assembly. Minor deductions include the unused constant _METHOD_NAME referencing an undefined variable (possibly hidden) and the slight abstraction overhead of the generic list, but these do not materially hinder comprehension.
Run 1
Code Structure: Small, focused methods and orderly imports make the organization clear, although the snippet lacks the class's closing brace and the definition of _METHOD_NAME. Nesting: Flat method bodies impose minimal cognitive load. Clarity of intent: Descriptive method and variable names clarify request handling and response construction, but the uncheckout behavior is not evident without the superclass or storage implementation. Code length: The implementation is concise; the lengthy license header adds little reading value but is conventional. Action granularity: Each statement performs a single clear action. Reading flow: Methods follow a natural progression from method identification to path extraction and response generation, with consistent formatting, though the wrapped signature slightly interrupts flow.
Run 2
Code Structure: Methods are clearly separated and logically organized, though the snippet lacks a closing class brace and the referenced _METHOD_NAME declaration. Nesting: Very flat, with no nested control flow. Clarity of intent: Descriptive class, method, and variable names make request handling and response construction understandable, although actual uncheckout behavior is not evident in this snippet. Code length: Implementation is concise; the lengthy license header adds visual overhead but is conventional. Action granularity: Each statement performs a single clear action, with intermediate variables aiding comprehension. Reading flow: Consistent indentation, spacing, and straightforward execution order make the code easy to follow; split method declarations slightly interrupt the flow.
Run 3
Code Structure: The class is logically organized into small, focused methods, with clean package and import sections. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive method and variable names make parameter retrieval and response construction easy to understand, though the uncheckout behavior depends on unseen inherited code and the method-name constant is not defined in the snippet. Code length: The implementation is concise; the lengthy license header adds reading overhead but is conventional. Action granularity: Each statement performs a distinct action, making execution easy to follow. Reading flow: Consistent indentation and straightforward sequencing support natural reading, although the wrapped method signature slightly interrupts flow. The missing final class brace makes the provided snippet appear incomplete.