Sample
Scalabrio12
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 57.3Δ 22.4 |
| Scalabrino | 0.694 | 0–1; higher is more readable | 70.4Δ 35.4 |
| Dorn | 0.038 | 0–1; higher is more readable | 6.5Δ 28.4 |
| Mi | 0.241 | 0–1; higher is more readable | 52.8Δ 17.8 |
| LLOC | 12 | Logical lines; fewer is more readable | 57.3Δ 22.4 |
| DeepSeek V4 Pro | 13.67 | 0–20; mean of three runs | 43.2Δ 8.3 |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs | 58.5Δ 23.6 |
| BTTF | 0.4 | 0–1; higher is more readable | 15.6Δ 19.3 |
| Human | 3.33 | 1–5; original rating | 34.9 |
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. | 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.
| Score | 0.694 |
|---|
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. | 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.
| Score | 0.241 |
|---|
| Score | 12 |
|---|
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.