Source code
Official dataset source · Scalabrio39
Sample
Scalabrio39
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.957 | 0–1; higher is more readable | 98.5Δ 0.8 |
| Scalabrino | 0.955 | 0–1; higher is more readable | 99.0Δ 0.3 |
| Dorn | 0.791 | 0–1; higher is more readable | 90.5Δ 8.8 |
| Mi | 0.791 | 0–1; higher is more readable | 97.0Δ 2.3 |
| LLOC | 8 | Logical lines; fewer is more readable | 76.9Δ 22.4 |
| DeepSeek V4 Pro | 17.67 | 0–20; mean of three runs | 96.0Δ 3.3 |
| GPT-6.1 Sol | 19 | 0–20; mean of three runs | 98.0Δ 1.3 |
| BTTF | 0.873 | 0–1; higher is more readable | 100.0Δ 0.8 |
| Human | 4.78 | 1–5; original rating | 99.2 |
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) |
|---|---|---|
| Source linesThe number of non-empty source lines. | 20 | +8 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 236.35 | −7.8 |
| Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value. | 3.982 | −5.974 |
Intercept 8.87 + feature contributions = 3.097 (log-odds).
Score = sigmoid(3.097) = 0.957.
| Score | 0.955 |
|---|
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. | 68 | +0.785 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 1 | −0.703 |
| 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. | 20 | +0.328 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.066 | +0.305 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 67.9 | +0.291 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 18.942 | −0.145 |
Intercept 0.07 + feature contributions = 1.33 (log-odds).
Score = sigmoid(1.33) = 0.791.
| Score | 0.791 |
|---|
| Score | 8 |
|---|
Run 1
The code is highly readable. It follows a clear, logical structure with flat nesting and early returns that make the intent obvious. Each condition is separated, and each action is on its own line, supporting natural reading flow. The only minor redundancy is the final `return true;` which could be simplified to `return super.equals(obj);`, but this does not significantly impact readability.
Run 2
The code is highly readable due to its flat, logical structure with early returns that avoid nesting. Each conditional check is a simple, separate line expressing clear intent: identity check, type check, and superclass equality check. The boolean returns are concise and avoid unnecessary if-else blocks. The Javadoc is thorough but not excessive. Minor deductions for the final 'return true;' after the super.equals() check being slightly redundant—could directly return super.equals(obj)—but this does not significantly harm readability. Overall, the code follows idiomatic Java equals() patterns and reads naturally from top to bottom.
Run 3
The code is highly readable. It is well-structured with clear sequential checks, flat nesting, and concise, single-purpose lines. The intent is obvious: standard equals implementation. The Javadoc adds clarity, though the final `return true` is somewhat redundant after the previous checks but remains clear and explicit.
Run 1
Code Structure: Checks are logically organized into identity, type, and superclass equality. Nesting: Flat guard clauses avoid nested conditionals. Clarity of intent: The equals method, annotation, and straightforward checks clearly communicate its purpose, though the documentation is generic. Code length: Short overall; the final conditional and return could be simplified to return super.equals(obj). Action granularity: Each statement performs a single action. Reading flow: The sequence is natural and easy to follow, with consistent formatting and early returns.
Run 2
Code Structure: Logically organized equality checks with straightforward early returns. Nesting: Flat control flow with no nested conditionals. Clarity of intent: The method name, override annotation, and type check clearly communicate its purpose; the documentation is understandable but generic. Code length: Short overall, though the final conditional and return could be replaced with return super.equals(obj). Action granularity: Each statement performs one action on its own line. Reading flow: Checks proceed naturally from identity to type compatibility to superclass equality.
Run 3
Code Structure: Logically organized equality checks, with identity, type, and superclass comparisons in sequence. Nesting: Flat guard clauses avoid deep nesting. Clarity of intent: The method name, annotation, and straightforward conditions clearly convey equality testing, although the documentation adds little detail. Code length: Concise overall; the final conditional could be simplified to return super.equals(obj). Action granularity: Each statement performs one action. Reading flow: Natural top-to-bottom progression with immediate returns makes the method easy to follow.