Sample

Scalabrio88

Human rating uses the original dataset scale.

DatasetScalabrino
Human3.67
Lines21

Scores

MethodScoreScaleDataset rank
(0–100)
Posnett00–1; higher is more readable
26.6Δ 26.4
Scalabrino0.1770–1; higher is more readable
13.1Δ 39.9
Dorn0.0180–1; higher is more readable
4.5Δ 48.5
Mi0.0810–1; higher is more readable
30.7Δ 22.4
LLOC16Logical lines; fewer is more readable
40.2Δ 12.8
DeepSeek V4 Pro6.670–20; mean of three runs
5.5Δ 47.5
GPT-6.1 Sol170–20; mean of three runs
58.5Δ 5.5
BTTF0.4790–1; higher is more readable
32.2Δ 20.9
Human3.671–5; original rating
53.0

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)
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.

Score0.177

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

Score0.081
Score16
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.