Sample
Dorn/java/175
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 30.4Δ 17.5 |
| Scalabrino | 0.516 | 0–1; higher is more readable | 43.8Δ 4.1 |
| Dorn | 0.884 | 0–1; higher is more readable | 93.3Δ 45.4 |
| Mi | 0.616 | 0–1; higher is more readable | 65.5Δ 17.5 |
| LLOC | 11 | Logical lines; fewer is more readable | 57.0Δ 9.1 |
| DeepSeek V4 Pro | 17 | 0–20; mean of three runs | 93.5Δ 45.5 |
| GPT-6.1 Sol | 17.67 | 0–20; mean of three runs | 88.9Δ 40.9 |
| BTTF | 0.601 | 0–1; higher is more readable | 73.8Δ 25.9 |
| Human | 3.33 | 1–5; original rating | 47.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. | 1353.194 | −44.655 |
| 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. | 4.905 | −7.358 |
Intercept 8.87 + feature contributions = -23.143 (log-odds).
Score = sigmoid(-23.143) = 0.
| Score | 0.516 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 47 | +0.889 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 50 | −0.734 |
| 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. | 73.922 | +0.534 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 74 | +0.39 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 49.667 | +0.284 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.077 | +0.198 |
Intercept 0.07 + feature contributions = 2.029 (log-odds).
Score = sigmoid(2.029) = 0.884.
| Score | 0.616 |
|---|
| Score | 11 |
|---|
Run 1
The code is well-structured with clear method separation and consistent patterns. Each method follows a logical flow: permission check followed by the actual operation. Nesting is minimal with no deep conditional blocks. Intent is clear through descriptive method names and proper exception declarations. Code length is appropriate - methods are concise without unnecessary verbosity. Action granularity is good, with each line performing a distinct operation. Reading flow is natural, with permission checks consistently preceding operations. Minor deductions: the repeated permission check pattern creates slight redundancy, and method parameters could benefit from alignment or formatting improvements. The import statements are properly organized, and the class follows Liferay service conventions well.
Run 2
The code is well-structured with clear separation of concerns and consistent patterns across methods. Each method follows a logical flow: permission check, then action. Nesting is minimal. Method names clearly express intent. The code avoids unnecessary length while maintaining clarity. Most lines perform a single action, though the CommonPermissionUtil.check calls span multiple lines but are still readable. The imports are organized, and the class has proper Javadoc. The reading flow is natural: validate permissions, then perform the operation. Minor deductions for the multi-line method signatures and throws clauses, which add slight visual noise.
Run 3
The code is well-structured with clear separation of concerns, following a service layer pattern. Methods are concise, each performing a single logical action (permission check, then delegating to local service or persistence). Nesting is minimal and flat. Naming is explicit, making intent clear. Reading flow is natural: input, permission check, operation. Minor deductions: repeated permission-check patterns could be extracted, and some lines (method signatures and permission checks) are somewhat long. Overall, highly readable.
Run 1
Code Structure: Methods are logically separated by operation and consistently organize permission checks before service calls or returns. Nesting: Flat method bodies contain no nested control flow. Clarity of intent: Descriptive method and variable names make each operation clear, though inherited dependencies require some framework familiarity. Code length: The methods are concise, with little unnecessary code; the unused User and List imports add minor clutter. Action granularity: Each statement performs a distinct action, and multiline calls remain easy to follow. Reading flow: Consistent formatting and the lookup-check-act pattern support natural reading. The missing closing class brace makes the provided snippet appear incomplete.
Run 2
Code Structure: Methods are logically separated into add, delete, and get operations, with consistent permission checks. Nesting: Flat method bodies are easy to follow. Clarity of intent: Descriptive method and variable names make the service's purpose clear, although inherited dependencies require external context. Code length: Concise, with little unnecessary code beyond an apparently unused User import. Action granularity: Each statement performs one main action; multiline calls remain readable. Reading flow: Consistent formatting and the retrieve-check-act pattern create a natural flow. The snippet lacks a closing class brace and imports for several referenced types, making it appear incomplete and slightly reducing readability.
Run 3
Code Structure: Clearly separated add, delete, and get methods organize related service operations logically. Nesting: Methods are flat, with no nested conditionals or loops. Clarity of intent: Descriptive method and variable names make the permission checks and service actions easy to understand. Code length: Methods are short and focused; repeated permission checks are reasonable for these operations. Action granularity: Each statement performs one distinct action, with multiline calls improving legibility. Reading flow: Retrieval, authorization, and execution follow a consistent, natural sequence. Minor drawbacks include an unused User import, missing visible imports for referenced types, and the absent final class-closing brace in the supplied snippet.