Sample

Scalabrio23

Human rating uses the original dataset scale.

DatasetScalabrino
Human3.22
Lines12

Scores

MethodScoreScaleDataset rank
(0–100)
Posnett0.1260–1; higher is more readable
86.4Δ 59.0
Scalabrino0.5450–1; higher is more readable
53.8Δ 26.4
Dorn0.1730–1; higher is more readable
22.6Δ 4.8
Mi0.1250–1; higher is more readable
39.7Δ 12.3
LLOC3Logical lines; fewer is more readable
96.5Δ 69.1
DeepSeek V4 Pro100–20; mean of three runs
19.3Δ 8.0
GPT-6.1 Sol170–20; mean of three runs
58.5Δ 31.2
BTTF0.5590–1; higher is more readable
60.3Δ 32.9
Human3.221–5; original rating
27.4

Views

Download official ZIP ↗

Select the downloaded ZIP or its extracted folder. Files stay in your browser.

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(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.

Score0.545

Feature contributions

FeatureValueContribution
(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.

Score0.125
Score3
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.