Sample
Scalabrio88
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 26.6Δ 26.4 |
| Scalabrino | 0.177 | 0–1; higher is more readable | 13.1Δ 39.9 |
| Dorn | 0.018 | 0–1; higher is more readable | 4.5Δ 48.5 |
| Mi | 0.081 | 0–1; higher is more readable | 30.7Δ 22.4 |
| LLOC | 16 | Logical lines; fewer is more readable | 40.2Δ 12.8 |
| DeepSeek V4 Pro | 6.67 | 0–20; mean of three runs | 5.5Δ 47.5 |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs | 58.5Δ 5.5 |
| BTTF | 0.479 | 0–1; higher is more readable | 32.2Δ 20.9 |
| Human | 3.67 | 1–5; original rating | 53.0 |
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. | 1107.925 | −36.562 |
| Source linesThe number of non-empty source lines. | 21 | +8.4 |
| 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.827 | −7.241 |
Intercept 8.87 + feature contributions = -26.532 (log-odds).
Score = sigmoid(-26.532) = 0.
| Score | 0.177 |
|---|
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. | 153 | −2.815 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 1 | −0.703 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 21 | +0.293 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 19.344 | −0.139 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.083 | +0.136 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 21 | −0.061 |
Intercept 0.07 + feature contributions = -4.024 (log-odds).
Score = sigmoid(-4.024) = 0.018.
| Score | 0.081 |
|---|
| Score | 16 |
|---|
Run 1
The code structure is logical and linear, testing return types and parameter guessing for date arithmetic. However, it is overly repetitive, with long lines wrapping multiple actions (query creation, assertions) that reduce readability. Nesting is flat, which is good, but the lack of helper methods or grouping makes the test verbose. Intent is clear but could be improved with better organization, such as a table of query/type pairs. The code is longer than necessary due to repeated assertion patterns.
Run 2
The code is a single, monolithic test method with deeply repetitive assertions and no helper methods or grouping. It uses long lines with multiple method calls per assert, and reuses a mutable 'translator' variable repeatedly, making the state hard to track. The test name is verbose but descriptive; however, the intent of each block is not clearly separated, forcing the reader to parse dense lines of chained calls. Nesting is flat (not the main issue), but action granularity is poor: each line combines message, expected value, and a multi-step method invocation. This harms readability significantly, though the code remains technically correct and uses consistent assertion patterns.
Run 3
The code is a single test method with no helper methods or comments explaining the scenarios. It repeats the same pattern of creating a translator and asserting return types, leading to a long, dense block. Multiple operations are packed onto single lines, violating the one-action-per-line guideline and making it harder to parse. The intent is somewhat clear—testing DateTime arithmetic return types and parameter guessing—but the lack of separation between cases hurts readability. Nesting is not an issue since it is flat, but the structure is monolithic and repetitive. Reading flow is choppy due to the absence of whitespace or grouping. Extracting helper methods or adding comments would greatly improve clarity and reduce length.
Run 1
Code Structure: The test is logically organized into query-and-assertion sequences, although several scenarios share one method. Nesting: The code is flat, with no nested control flow. Clarity of intent: The descriptive method name, explicit queries, and assertion messages clearly communicate the tested behavior. Code length: It is reasonably concise, but repeated return-type assertions could be extracted into a helper. Action granularity: Each statement performs one clear action on its own line. Reading flow: Setup followed by assertions creates a natural flow; however, inconsistent spacing between scenarios, long assertion lines, and repeated reassignment of translator slightly reduce readability.
Run 2
Code Structure: Logically groups query translation and assertions, though multiple scenarios share one test and repeatedly reassign the translator. Nesting: Completely flat, making execution easy to follow. Clarity of intent: The descriptive test name, explicit queries, and expected types clearly communicate the purpose; generic assertion messages provide limited scenario-specific context. Code length: Reasonably short, but repeated return-type assertions could be extracted into a helper. Action granularity: Each statement performs a single setup or assertion action. Reading flow: Consistent setup-then-assert sequencing is natural, although long assertion lines and uneven blank-line grouping slightly reduce scanability.
Run 3
Code Structure: Logically groups related date arithmetic and parameter-type tests, though separate test methods could better isolate scenarios. Nesting: Completely flat, making execution easy to follow. Clarity of intent: The descriptive method name, explicit queries, and expected types communicate the purpose clearly; repeated generic assertion messages provide limited scenario context. Code length: Reasonably concise, but repeated return-type assertions could be extracted into a helper. Action granularity: Each statement performs one setup or assertion action. Reading flow: Consistent setup-then-assert sequencing is natural, with blank lines separating some scenarios; long assertion lines and repeated translator reassignment slightly reduce readability.