Sample
Dorn/java/111
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 35.7Δ 25.3 |
| Scalabrino | 0.533 | 0–1; higher is more readable | 48.8Δ 12.2 |
| Dorn | 0.558 | 0–1; higher is more readable | 48.7Δ 12.3 |
| Mi | 0.339 | 0–1; higher is more readable | 32.9Δ 28.1 |
| LLOC | 18 | Logical lines; fewer is more readable | 38.4Δ 22.6 |
| DeepSeek V4 Pro | 11 | 0–20; mean of three runs | 46.4Δ 14.6 |
| GPT-6.1 Sol | 14.33 | 0–20; mean of three runs | 44.4Δ 16.6 |
| BTTF | 0.533 | 0–1; higher is more readable | 55.2Δ 5.8 |
| Human | 3.46 | 1–5; original rating | 61.0 |
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. | 1243.274 | −41.028 |
| 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.927 | −7.39 |
Intercept 8.87 + feature contributions = -19.548 (log-odds).
Score = sigmoid(-19.548) = 0.
| Score | 0.533 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| 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. | 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. | 70.98 | +0.659 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 34 | +0.439 |
| 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.542 | +0.283 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.105 | −0.078 |
Intercept 0.07 + feature contributions = 0.232 (log-odds).
Score = sigmoid(0.232) = 0.558.
| Score | 0.339 |
|---|
| Score | 18 |
|---|
Run 1
The code demonstrates moderate readability but has several structural issues. The structure is somewhat logical with try-catch blocks separating error handling, but the error handling pattern is repetitive and verbose. Nesting levels are acceptable with only 2-3 levels deep, though the role name check creates additional nesting. Clarity of intent is reasonable - the purpose of checking for restricted roles is clear, but the exception handling logic is convoluted. Code length is unnecessarily long for the operations performed, particularly in the error handling sections. Action granularity is mostly good with one operation per line. Reading flow is disrupted by the exception handling interrupting the main logic. The code could be improved by extracting error handling into reusable methods or using multi-catch blocks, and the exception type checking could be simplified. The duplication of error handling patterns between the two methods also reduces overall readability.
Run 2
The code is moderately readable but has several issues. The structure is logically organized into try-catch blocks with nested conditionals, but the nesting depth (try > catch > if > else > throw) adds complexity. Intent is mostly clear - handling exceptions and redirecting/setting forwards based on role validation - though the exception handling pattern is repetitive. Code length is reasonable but the instanceof checks could be simplified. Action granularity is good with one action per line. Reading flow is natural for Java exception handling but the duplicated exception handling blocks and multiple throw statements create visual noise. The code would benefit from extraction of the exception handling logic and reduced nesting.
Run 3
The code is difficult to follow due to excessive nesting (try-catch with nested if-else and type checks), poor formatting with odd indentation, and unclear intent. Multiple actions are packed into blocks, and the flow is disorganized. Exception handling is verbose and repetitive, making the logic harder to parse. While variable names are somewhat clear, the overall structure hampers readability.
Run 1
Code Structure: The render method logically separates retrieval, validation, and error handling, but the fragment starts mid-method and ends incomplete. Nesting: Moderate nesting in try/catch and conditional blocks adds some reading effort. Clarity of intent: Descriptive method names and constants make role validation and error forwarding understandable, although the reason for rejecting these roles is unstated. Code length: Mostly concise, with some verbosity from generic exception catches and instanceof checks. Action granularity: Each statement performs one clear action, and whitespace separates related operations. Reading flow: Consistent formatting supports a natural progression from retrieval to validation to exception handling, but the incomplete boundaries and wrapped conditions interrupt readability.
Run 2
Code Structure: The render method logically groups resource retrieval, role validation, and error handling, but the fragment starts mid-method and ends before completion. Nesting: Moderate nesting in the try block and exception handlers adds some reading effort. Clarity of intent: Descriptive method names and exception types communicate validation and error routing clearly, although the reason for rejecting specific roles is unexplained. Code length: Mostly concise, with slightly verbose generic exception handling and rethrow branches. Action granularity: Each statement performs one distinct action, making operations easy to follow. Reading flow: Consistent indentation and spacing support readability, but multiline conditions and the incomplete surrounding context interrupt the flow.
Run 3
Code Structure: The render method logically groups resource loading, role validation, and exception handling, but the excerpt begins mid-method and ends without completion. Nesting: Several nested conditionals inside try/catch blocks increase reading effort, though depth remains manageable. Clarity of intent: Descriptive method names, role constants, and error forwards make validation and failure handling understandable; the reason for rejecting specific roles is not explained. Code length: Mostly concise, with some repetitive exception-handling logic. Action granularity: Statements generally perform one action each, and compound conditions are split across lines. Reading flow: Consistent indentation and spacing support sequential reading, but the incomplete boundaries and broad exception catches with type checks interrupt the flow.