Sample
Dorn/python/23
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 51.8Δ 26.6 |
| Scalabrino | 0.478 | 0–1; higher is more readable | 38.8Δ 13.6 |
| Dorn | 0.357 | 0–1; higher is more readable | 28.7Δ 3.5 |
| Mi | 0.194 | 0–1; higher is more readable | 20.1Δ 5.2 |
| LLOC | 7 | Logical lines; fewer is more readable | 67.7Δ 42.5 |
| DeepSeek V4 Pro | 14 | 0–20; mean of three runs | 65.9Δ 40.7 |
| GPT-6.1 Sol | 16.67 | 0–20; mean of three runs | 73.8Δ 48.6 |
| BTTF | 0.492 | 0–1; higher is more readable | 43.2Δ 18.0 |
| Human | 2.93 | 1–5; original rating | 25.2 |
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. | 478.317 | −15.784 |
| 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.348 | −6.523 |
| Source linesThe number of non-empty source lines. | 10 | +4 |
Intercept 8.87 + feature contributions = -9.437 (log-odds).
Score = sigmoid(-9.437) = 0.
| Score | 0.478 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| 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 (horizontal)How rapidly the visual pattern of identifier characters changes from left to right. It measures spatial frequency, not the meaning of the names. | 70.909 | +0.662 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 11 | +0.647 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.136 | −0.375 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 9.431 | −0.278 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 10 | +0.191 |
Intercept 0.07 + feature contributions = -0.59 (log-odds).
Score = sigmoid(-0.59) = 0.357.
| Score | 0.194 |
|---|
| Score | 7 |
|---|
Run 1
The code is concise and readable, with clear intent: testing removal of a child and verifying an observer notification. Structure is logical, with flat nesting and one action per line. Lines are short and natural to follow. Minor deductions include the truncated context (missing class/method definition and indentation), making the first line's purpose slightly ambiguous, and the line-wrapped observer registration call could be slightly cleaner. Overall, it is highly readable for unit test code.
Run 2
The code is moderately readable. It uses clear, descriptive method names and consistent indentation. Each line performs a single action, which aids granularity. However, readability is hindered by a lack of surrounding context—the snippet appears to be part of a larger test class, but the fixture setup and teardown are missing. The first few lines seem to belong to a previous test method, causing a disorganized reading flow. Nesting is flat and structure is acceptable, but the intent of the first block is unclear without the preceding test method definition. The second test method is more focused, yet the inline observer registration spans multiple lines in a slightly awkward way. Overall, the code is understandable but would benefit from better separation of test methods and more context.
Run 3
The code is structured as test methods but consists of fragmented snippets, making context and intent unclear. It has a flat nesting structure, which is positive, but the lack of surrounding class or function definitions hurts logical organization. The first block performs add/remove/assert sequentially, which is readable, but the second method has a long function call split across lines, reducing clarity. Action granularity is mostly one action per line, aiding readability, but some lines contain chained or multi-argument calls that add visual clutter. The reading flow is natural within each snippet but abrupt due to missing context. Overall, the code is moderately readable because of simple operations and low nesting, but the lack of full method definitions, descriptive variable names, and clear test setup prevents a higher score.
Run 1
Code Structure: Test operations are logically grouped, though the excerpt begins mid-method. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: The method name and assertions clearly convey testing child removal and add-child notifications, although setup and event collection are not shown. Code length: Concise, with no unnecessary statements. Action granularity: Each statement performs one primary action; nested calls in assertions remain manageable. Reading flow: Setup, action, and verification follow a natural sequence. Slightly awkward continuation indentation and repeated event-type calls mildly reduce readability.
Run 2
Code Structure: Logically organized as test setup, action, and assertion, although the opening lines lack their enclosing method context. Nesting: Flat statements with no complex branching. Clarity of intent: The method name and assertions clearly indicate child removal and addition-notification tests; fixture definitions are not shown. Code length: Concise, with no unnecessary statements. Action granularity: Each statement performs one primary action; nested calls in assertions remain manageable. Reading flow: Operations follow a natural sequence, but inconsistent continuation indentation and repeated event-type expressions slightly interrupt readability.
Run 3
Code Structure: The visible test steps are logically organized, though the snippet begins mid-method and lacks surrounding context. Nesting: Flat statements with no nested control flow make it easy to scan. Clarity of intent: Descriptive method and API names clearly convey child removal and notification testing. Code length: Concise, with no unnecessary statements. Action granularity: Each statement performs one main action, although constructing an event inside an assertion slightly increases cognitive load. Reading flow: Setup, action, and assertion follow a natural testing sequence; awkward continuation indentation and the incomplete opening slightly disrupt the flow.