Sample
Scalabrio23
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.126 | 0–1; higher is more readable | 86.4Δ 59.0 |
| Scalabrino | 0.545 | 0–1; higher is more readable | 53.8Δ 26.4 |
| Dorn | 0.173 | 0–1; higher is more readable | 22.6Δ 4.8 |
| Mi | 0.125 | 0–1; higher is more readable | 39.7Δ 12.3 |
| LLOC | 3 | Logical lines; fewer is more readable | 96.5Δ 69.1 |
| DeepSeek V4 Pro | 10 | 0–20; mean of three runs | 19.3Δ 8.0 |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs | 58.5Δ 31.2 |
| BTTF | 0.559 | 0–1; higher is more readable | 60.3Δ 32.9 |
| Human | 3.22 | 1–5; original rating | 27.4 |
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) |
|---|---|---|
| Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value. | 5.328 | −7.992 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 230.624 | −7.611 |
| Source linesThe number of non-empty source lines. | 12 | +4.8 |
Intercept 8.87 + feature contributions = -1.933 (log-odds).
Score = sigmoid(-1.933) = 0.126.
| Score | 0.545 |
|---|
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. | 123 | −1.545 |
| 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. | 12 | +0.611 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.041 | +0.54 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 12 | −0.322 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 10.815 | −0.259 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 12 | +0.145 |
Intercept 0.07 + feature contributions = -1.563 (log-odds).
Score = sigmoid(-1.563) = 0.173.
| Score | 0.125 |
|---|
| Score | 3 |
|---|
Run 1
The code demonstrates good readability overall. The test method has a clear, descriptive name and a single purpose. The SQL query string is formatted as a concatenation of logical chunks, making the final SQL structure understandable. However, the formatting is suboptimal: the assertion arguments are indented excessively, and the string concatenation makes the SQL difficult to copy or modify. The nested parentheses in the SQL are hard to trace without careful reading. The code is reasonably concise but the SQL complexity pushes it toward the longer side. Action granularity is acceptable—one assertion with readable arguments. Reading flow is generally natural, though the deep indentation and concatenation break the flow slightly. Overall, it's readable but could be improved with a text block or constant for the expected SQL.
Run 2
The code has some positive aspects: a clear, single-purpose test method, informative naming, and relatively flat nesting. However, readability is significantly hurt by the extremely long SQL string constructed via concatenation. This obscures intent, makes the expected value hard to verify or modify, and disrupts natural reading flow. The method mixes multiple actions (building SQL, asserting equality) with dense, multi-line formatting. While the structure is logically simple, the lack of string formatting (e.g., text blocks) or named constants reduces clarity. Granularity is uneven — one logical assertion spans many lines without visual breaks. Overall, the code is functional but not reader-friendly.
Run 3
The code has some readability issues. The structure is relatively flat, but the core assertion contains a very long, concatenated SQL string that spans multiple lines, making it hard to parse visually. While the method name and annotations clearly indicate intent, the actual test logic is obscured by the SQL formatting. Action granularity is reasonable (one assertion), but the SQL construction is cluttered. Reading flow suffers because the expected SQL is difficult to scan. Better formatting or extracting the SQL into separate constants/variables would greatly improve clarity.
Run 1
Code Structure: A well-organized unit test separates the input query from the assertion, with annotations providing context. Nesting: Control flow is flat, although the assertion contains a short chain of method calls. Clarity of intent: The descriptive test name and explicit expected SQL clearly communicate what is being tested. Code length: The test is concise, but long SQL strings require careful reading. Action granularity: The query assignment is separate; the assertion combines handler construction, SQL processing, and comparison in one expression. Reading flow: Input followed by expected-versus-actual comparison is natural. Consistent indentation helps, while string concatenation and embedded SQL complexity slightly reduce readability.
Run 2
Code Structure: A well-organized test with a query definition followed by one assertion. Nesting: Minimal Java nesting; nested SQL and chained method calls add some complexity. Clarity of intent: The descriptive method name and issue annotation clearly identify the test's purpose, though the pagination transformation requires SQL knowledge. Code length: Concise overall, but the long expected SQL string is visually dense. Action granularity: Statements are clearly separated; the assertion combines handler creation, row-selection configuration, and SQL extraction in one expression. Reading flow: Natural setup-to-verification progression, slightly hindered by long concatenated strings and heavy indentation.
Run 3
Code Structure: The test is logically organized into query setup followed by an assertion. Nesting: Control flow is flat, with only modest nesting of method calls. Clarity of intent: The descriptive test name and issue annotation clearly establish the scenario, although the lengthy expected SQL requires careful reading. Code length: The test is concise overall, but long SQL literals make it visually dense. Action granularity: Setup and verification are separate statements; chaining within the assertion slightly increases cognitive load. Reading flow: The setup-to-assertion progression is natural, and multiline formatting helps, though concatenated SQL strings and heavy indentation interrupt scanning.