Sample
Scalabrio60
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 70.4Δ 4.3 |
| Scalabrino | 0.545 | 0–1; higher is more readable | 54.3Δ 11.8 |
| Dorn | 0.196 | 0–1; higher is more readable | 24.6Δ 41.5 |
| Mi | 0.186 | 0–1; higher is more readable | 44.7Δ 21.4 |
| LLOC | 13 | Logical lines; fewer is more readable | 53.0Δ 13.1 |
| DeepSeek V4 Pro | 15.67 | 0–20; mean of three runs | 72.9Δ 6.8 |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs | 83.7Δ 17.6 |
| BTTF | 0.43 | 0–1; higher is more readable | 18.6Δ 47.5 |
| Human | 3.89 | 1–5; original rating | 66.1 |
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. | 495.514 | −16.352 |
| 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.141 | −6.212 |
| Source linesThe number of non-empty source lines. | 12 | +4.8 |
Intercept 8.87 + feature contributions = -8.894 (log-odds).
Score = sigmoid(-8.894) = 0.
| Score | 0.545 |
|---|
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 |
| 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. | 101 | −0.613 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 12 | +0.611 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 9 | −0.426 |
| 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.137 | −0.389 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 10.853 | −0.258 |
Intercept 0.07 + feature contributions = -1.41 (log-odds).
Score = sigmoid(-1.41) = 0.196.
| Score | 0.186 |
|---|
| Score | 13 |
|---|
Run 1
The code is logically structured and follows a clear pattern for an equals method, checking identity first, then class compatibility, and finally field equality. Nesting is minimal, with early returns keeping the flow flat and readable. The intent is clear: to implement a standard equals contract. Code length is concise and appropriate for the task. Each line performs one logical action, maintaining good granularity. However, the ternary conditions for name and surname are somewhat dense and could be improved by using Objects.equals() or a utility method, which would enhance readability. Overall, the method is easy to follow but slightly hindered by the compact null-safe comparisons.
Run 2
The code is generally readable with a flat structure, early returns, and clear intent. It uses guard clauses effectively to handle equality checks. The ternary condition for name and surname adds minor complexity but is a standard pattern for null-safe comparison. Action granularity is good, with mostly one action per line. The reading flow is natural, with simple conditions returning false before the final true. Minor improvements could include extracting a helper method for null-safe field comparison to reduce repetition, but overall the code is concise and understandable.
Run 3
The code is clear and logically structured. It follows a standard equals() pattern with early returns, avoiding deep nesting. Intent is obvious: compare object identity, type, and fields. Each line performs a single logical check, improving readability. The ternary in the name/surname checks is slightly dense but acceptable. The only structural improvement would be using Objects.equals() to reduce length, but overall the code is concise, flat, and easy to follow.
Run 1
Code Structure: Logically organized into identity, type, and field comparisons. Nesting: Guard clauses keep the method flat. Clarity of intent: Equality checking is clear, although the null-safe ternary comparisons require extra attention. Code length: Concise without unnecessary steps. Action granularity: Each line performs one check or assignment, though inline returns compress conditions and outcomes. Reading flow: Natural progression from quick checks to individual fields and the final result. Overall, highly readable; braces and simpler null-safe comparisons could improve scanability.
Run 2
Code Structure: logically organized into identity, type, and field comparisons. Nesting: flat, with early returns avoiding nested conditionals. Clarity of intent: clearly implements Person equality, though the ternary null checks require extra attention. Code length: concise without unnecessary statements. Action granularity: each line contains one comparison and its associated return, although inline conditionals are slightly less scannable than braced blocks. Reading flow: natural progression from quick checks to detailed comparisons and final success.
Run 3
Code Structure: Logically organized into identity and type checks, casting, and field comparisons. Nesting: Early returns keep the method flat. Clarity of intent: The equality-checking purpose is clear, though the null-safe ternary expressions require extra attention. Code length: Concise without unnecessary statements. Action granularity: Each line contains one check or assignment, although inline returns slightly compress the conditional formatting. Reading flow: Checks proceed naturally from quick exclusions to individual field comparisons and final success.