Sample
Scalabrio56
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 19.1Δ 15.8 |
| Scalabrino | 0.503 | 0–1; higher is more readable | 49.7Δ 14.8 |
| Dorn | 0.203 | 0–1; higher is more readable | 26.1Δ 8.8 |
| Mi | 0.292 | 0–1; higher is more readable | 56.3Δ 21.4 |
| LLOC | 27 | Logical lines; fewer is more readable | 9.5Δ 25.4 |
| DeepSeek V4 Pro | 13.67 | 0–20; mean of three runs | 43.2Δ 8.3 |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs | 58.5Δ 23.6 |
| BTTF | 0.386 | 0–1; higher is more readable | 12.1Δ 22.9 |
| Human | 3.33 | 1–5; original rating | 34.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. | 1395.949 | −46.066 |
| Source linesThe number of non-empty source lines. | 35 | +14 |
| 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.837 | −7.255 |
Intercept 8.87 + feature contributions = -30.452 (log-odds).
Score = sigmoid(-30.452) = 0.
| Score | 0.503 |
|---|
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. | 119 | −1.375 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 118.971 | +1.115 |
| 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. | 27 | −0.199 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 34 | −0.167 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.114 | −0.164 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 33.125 | +0.053 |
Intercept 0.07 + feature contributions = -1.37 (log-odds).
Score = sigmoid(-1.37) = 0.203.
| Score | 0.292 |
|---|
| Score | 27 |
|---|
Run 1
The code demonstrates reasonable structure with a clear test method and logical sequencing of test scenarios. It is mostly flat with minimal nesting. However, readability is reduced by multiple concerns: the test name 'testBasicHiLoOptimizerUsage' is generic and doesn't convey the specific behavior being verified; the method is fairly long and combines two distinct test scenarios in one method; there is some type casting and inline comments that are necessary but not always clear. The action granularity is generally good, with one assertion per line. Reading flow could be improved by splitting into separate test methods with more descriptive names, and by using constants for magic numbers like 1, 11, 2, and 3. The comments help explain intent but the code would benefit from more self-documenting structure and better naming.
Run 2
The code has clear intent with descriptive test method name, inline comments, and logical grouping of assertions. It follows a linear, readable flow with test setup, execution, and verification. However, readability is reduced by duplicated blocks with minor variations, repeated casts and assertions, and a somewhat tangled mix of comments explaining behavior rather than extracting helper methods or parameterized tests. Nesting is shallow and action granularity is reasonable, though some lines combine actions. The code is moderately concise but would benefit from reducing duplication and clarifying magic numbers (e.g., -1, 10, 11).
Run 3
The test is logically structured and follows a clear sequence of setup, execution, and verification. It uses a loop to avoid repetition and includes helpful comments explaining intent. However, readability suffers from several issues: variable declarations at the top (`Long next`) and repeated casts add noise; multiple assertions are packed onto single lines; and the mock/optimizer setup is not reusable. The code is somewhat long for the concept tested, and the historic-vs-table behavior distinction is explained only through comments, not clear helper methods or variable names. The nesting is shallow, and action granularity is acceptable, but the flow would benefit from extracting repeated patterns into helper methods and separating assertion concerns. Overall, it's understandable but not exceptionally clean or concise.
Run 1
Code Structure: Two logically organized scenarios cover sequence and table behavior, though separate test methods or a shared helper would reduce duplication. Nesting: Only shallow for-loops, making control flow easy to follow. Clarity of intent: The test name, comments, and assertions communicate expected optimizer behavior; the unexplained -1 argument and phrase "clock over" are less clear. Code length: Reasonably concise, but both scenarios repeat nearly identical generation and assertion steps. Action granularity: Each line generally performs one assignment or assertion. Reading flow: Setup, generation, and verification proceed naturally in each scenario, although reusing sequence and optimizer requires tracking their reassignment. Comment typos slightly detract from polish.
Run 2
Code Structure: Two logically organized test scenarios are clearly separated by comments, though separate test methods would improve isolation. Nesting: Only shallow for-loops, making control flow easy to follow. Clarity of intent: Descriptive method and variable names, explanatory comments, and explicit assertions communicate the expected optimizer behavior; 'clock over' and the unexplained -1 argument are less clear. Code length: Reasonably concise, but both scenarios repeat nearly identical setup, generation, and assertions. Action granularity: Each statement performs one action, with assertions on separate lines. Reading flow: Setup, generation, verification, and rollover checks follow a natural sequence. Reusing variables across scenarios and minor comment typos slightly reduce polish.
Run 3
Code Structure: Two logically grouped scenarios clearly separate sequence and table behavior, though separate test methods could improve organization. Nesting: Only shallow loops, making control flow easy to follow. Clarity of intent: The descriptive method name, comments, and explicit assertions explain expected behavior; unexplained -1 and the phrase "clock over" introduce minor ambiguity. Code length: Reasonably concise, but repeated setup, loops, and assertions add duplication. Action granularity: Each statement performs one clear action, with assertions individually expressed. Reading flow: Setup, generation, and verification proceed naturally in both scenarios, although reusing variables and minor comment typos slightly reduce polish.