Sample
Scalabrio32
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.091 | 0–1; higher is more readable | 85.9Δ 2.0 |
| Scalabrino | 0.858 | 0–1; higher is more readable | 89.9Δ 2.0 |
| Dorn | 0.526 | 0–1; higher is more readable | 60.8Δ 27.1 |
| Mi | 0.354 | 0–1; higher is more readable | 63.3Δ 24.6 |
| LLOC | 6 | Logical lines; fewer is more readable | 86.9Δ 1.0 |
| DeepSeek V4 Pro | 17 | 0–20; mean of three runs | 90.2Δ 2.3 |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs | 83.7Δ 4.3 |
| BTTF | 0.648 | 0–1; higher is more readable | 82.9Δ 5.0 |
| Human | 4.33 | 1–5; original rating | 87.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. | 381.56 | −12.591 |
| Source linesThe number of non-empty source lines. | 21 | +8.4 |
| 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.655 | −6.983 |
Intercept 8.87 + feature contributions = -2.304 (log-odds).
Score = sigmoid(-2.304) = 0.091.
| Score | 0.858 |
|---|
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. | 120.952 | −1.458 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 121 | +1.148 |
| 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.047 | +0.489 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 21 | +0.293 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 19.82 | −0.133 |
Intercept 0.07 + feature contributions = 0.104 (log-odds).
Score = sigmoid(0.104) = 0.526.
| Score | 0.354 |
|---|
| Score | 6 |
|---|
Run 1
The code is well-structured with a clear single purpose: returning a PropertyAccessor based on entity mode. The Javadoc explains parameters and exceptions. The if-else chain is flat and easy to follow, with three logical branches (null/POJO, MAP, unknown). Each branch performs one action, improving granularity. No deep nesting or tangled logic. Variable/parameter names are descriptive. The TODO comment flags temporary design, which helps future maintainers. Minor deductions: the 'MappingException' message could be more specific, and the initial null check on 'mode' could be slightly clearer if separated. Overall, readable and concise.
Run 2
The code is highly readable with clear logical organization and flat structure. The intent is immediately apparent: retrieve a PropertyAccessor based on entity mode. Nesting is minimal (single-level if/else-if/else), and the reading flow is natural. Action granularity is appropriate—each branch performs one action. Although Javadoc is somewhat verbose and the TODO comment adds a minor distraction, the method remains concise and well-structured. The null-handling for mode and meaningful exception message further enhance clarity.
Run 3
The code is generally readable with clear logic and good Javadoc documentation. It has a flat structure with minimal nesting and each action is on its own line. However, there are minor indentation inconsistencies and the TODO comment references an unresolved design concern.
Run 1
Code Structure: A logically organized conditional selects the appropriate accessor or throws an exception. Nesting: Shallow branching keeps the method easy to follow. Clarity of intent: Descriptive method names and Javadoc explain its purpose, although treating null as POJO is implicit and the TODO references Property rather than AttributeBinding. Code length: Concise overall, with slightly redundant else blocks after return statements. Action granularity: Each statement performs one clear action. Reading flow: The POJO-to-MAP-to-error sequence is natural, but inconsistent indentation and spacing mildly reduce readability.
Run 2
Code Structure: A logically organized method separates accessor selection into clear branches. Nesting: Shallow conditional nesting keeps the logic easy to follow. Clarity of intent: Descriptive method names and documentation explain the purpose, though the outdated TODO referencing Property rather than AttributeBinding adds minor confusion. Code length: Concise, with no unnecessary implementation complexity; else blocks after returns could be omitted. Action granularity: Each statement performs one action, although the first condition combines two related cases. Reading flow: The sequence from default/POJO handling to MAP handling and unsupported-mode failure is natural. Inconsistent indentation and spacing slightly reduce readability.
Run 3
Code Structure: A logically organized method selects an accessor by entity mode and rejects unsupported modes. Nesting: A single, shallow if/else chain is easy to follow. Clarity of intent: Descriptive method names and Javadoc explain the purpose, though the outdated TODO references Property rather than AttributeBinding. Code length: Concise overall, with slightly unnecessary else blocks after returning branches. Action granularity: Each statement performs one clear action. Reading flow: Conditions progress naturally from POJO/default mode to MAP mode and then error handling; inconsistent indentation and spacing slightly detract from readability.