Sample

Scalabrio12

Human rating uses the original dataset scale.

DatasetScalabrino
Human3.33
Lines19

Scores

MethodScoreScaleDataset rank
(0–100)
Posnett00–1; higher is more readable
57.3Δ 22.4
Scalabrino0.6940–1; higher is more readable
70.4Δ 35.4
Dorn0.0380–1; higher is more readable
6.5Δ 28.4
Mi0.2410–1; higher is more readable
52.8Δ 17.8
LLOC12Logical lines; fewer is more readable
57.3Δ 22.4
DeepSeek V4 Pro13.670–20; mean of three runs
43.2Δ 8.3
GPT-6.1 Sol170–20; mean of three runs
58.5Δ 23.6
BTTF0.40–1; higher is more readable
15.6Δ 19.3
Human3.331–5; original rating
34.9

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.691.973−22.835
Source linesThe number of non-empty source lines.19+7.6
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.282−6.422

Intercept 8.87 + feature contributions = -12.788 (log-odds).
Score = sigmoid(-12.788) = 0.

Score0.694

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.147.947−2.601
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.1+1.001
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
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.17.745−0.162
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.19−0.015
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.098−0.007

Intercept 0.07 + feature contributions = -3.222 (log-odds).
Score = sigmoid(-3.222) = 0.038.

Score0.241
Score12
Run 1

The code is moderately readable. It has a clear structure with setup, execution, and assertion phases, but suffers from unnecessary verbosity due to anonymous inner classes that obscure the main test flow. Nesting is moderate—two anonymous classes add indentation and mental overhead. Clarity of intent is decent, but the purpose of overriding printFailures and the expected output format could be clearer. Code length is somewhat long for what it tests; helper methods or lambdas could reduce boilerplate. Action granularity is fair—most lines perform one logical action, though some declarations are verbose. Reading flow is mostly natural but interrupted by inline anonymous class definitions. Overall, the code is understandable but could be more concise and expressive.

Run 2

The code is moderately readable but has several issues. The structure is logical with clear setup, execution, and assertion phases. However, the nested anonymous classes increase complexity and reduce readability. The intent is somewhat clear - testing failure output - but the expected string with format specifiers is ambiguous. The code is appropriately concise but packs multiple conceptual actions into single lines (e.g., suite.addTest with nested anonymous class). Reading flow is disrupted by the anonymous TestCase implementation breaking the natural sequence. The lambda-like overrides would be clearer with named classes or lambdas. Overall, the code works but requires careful reading to understand what's being tested and how the pieces connect.

Run 3

The code is reasonably structured and readable, with a clear test setup and execution flow. The nesting is moderate: one anonymous class inside a method, plus another inside a test suite, which is typical for JUnit-style tests but increases conceptual overhead. Intent is mostly clear—simulate a failing test and check output—but some details like the expected string are opaque without context. Length is acceptable for a test method, though the inline anonymous class for TestCase could be extracted for clarity. Action granularity is good, with one logical action per line. Reading flow is mostly natural, but jumping between setup, anonymous class definitions, and assertions slightly disrupts the flow. Overall, it’s functional and understandable but could benefit from minor refactoring to reduce nesting and clarify the expected output format.

Run 1

Code Structure: Well-organized test with a clear setup, execution, and assertion sequence. Nesting: Two anonymous classes introduce moderate nesting, but their overridden methods are short and easy to follow. Clarity of intent: The deliberate assertion failure and expected output clearly communicate what is being tested, though testFailure is a broad name. Code length: Concise overall; the long expected-output initialization would be easier to scan across multiple lines. Action granularity: Most statements perform one action, with inline object construction adding minor complexity. Reading flow: Natural progression from expected output and printer configuration to test creation, execution, and verification.

Run 2

Code Structure: Logically organized into expected output, printer setup, failing test setup, execution, and assertion. Nesting: Two anonymous classes introduce moderate nesting, but their methods are short and easy to follow. Clarity of intent: The method name, deliberate AssertionFailedError, and final assertion clearly communicate a failure-output test. Code length: Concise overall, although the long expected-output array would be easier to scan across multiple lines. Action granularity: Most statements perform one action; inline object construction adds slight complexity. Reading flow: Follows a natural arrange-act-assert sequence, with consistent indentation and clear transitions between setup and execution.

Run 3

Code Structure: Logically organized into expected output, printer setup, failing test construction, execution, and assertion. Nesting: Limited nesting from two anonymous classes and their overridden methods; manageable but slightly interrupts scanning. Clarity of intent: The method name, deliberate AssertionFailedError, and final assertion clearly indicate a failure-output test, though external helpers and fields require context. Code length: Concise overall, but the expected-output array is crowded onto one long line. Action granularity: Statements generally perform one action each, with only modest inline object construction. Reading flow: Follows a natural arrange-act-assert progression; consistent indentation helps, while anonymous classes and the dense expected string list add minor friction.