Sample
Dorn/python/85
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 52.1Δ 33.1 |
| Scalabrino | 0.499 | 0–1; higher is more readable | 41.9Δ 22.9 |
| Dorn | 0.45 | 0–1; higher is more readable | 39.0Δ 20.1 |
| Mi | 0.145 | 0–1; higher is more readable | 14.5Δ 4.5 |
| LLOC | 9 | Logical lines; fewer is more readable | 61.3Δ 42.3 |
| DeepSeek V4 Pro | 14.33 | 0–20; mean of three runs | 69.9Δ 51.0 |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs | 93.5Δ 74.5 |
| BTTF | 0.509 | 0–1; higher is more readable | 47.6Δ 28.7 |
| Human | 2.76 | 1–5; original rating | 18.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. | 471.061 | −15.545 |
| 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.486 | −6.729 |
| Source linesThe number of non-empty source lines. | 10 | +4 |
Intercept 8.87 + feature contributions = -9.404 (log-odds).
Score = sigmoid(-9.404) = 0.
| Score | 0.499 |
|---|
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 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 11 | +0.647 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 7 | −0.495 |
| 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. | 78 | +0.361 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 9.722 | −0.274 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 10 | +0.191 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.086 | +0.103 |
Intercept 0.07 + feature contributions = -0.201 (log-odds).
Score = sigmoid(-0.201) = 0.45.
| Score | 0.145 |
|---|
| Score | 9 |
|---|
Run 1
The code is structured in a linear, mostly readable sequence, with each line performing a distinct action. Function and variable names clearly convey intent, such as 'testMarkLastGrandChildCompletedMakesParentRecur' and 'expectedPlannedStartDateTime'. However, readability is reduced by the conditional block that intermixes calculation logic with test setup, making the flow less direct. The final assertion is split across two lines for length, but the line break occurs at a logical point. Nesting is minimal, which is good. The main weaknesses are the slightly ambiguous role of the 'if' block and the reliance on external state (self.now, self.parent, etc.) without inline context. Overall, the code is reasonably clear but could benefit from grouping setup, condition evaluation, and assertion phases more explicitly.
Run 2
The code is relatively understandable but has issues with clarity and structure. The test setup lines are concise and mostly one action per line, but the conditional block introduces unnecessary nesting and makes the reading flow less natural. The variable 'shouldMarkCompletedWhenAllChildrenCompleted' is expressive, but the purpose of the conditional and the recurrence logic is somewhat ambiguous without context. The method name is descriptive, but the body could benefit from comments or helper methods to clarify intent. Overall, the code is acceptable but not exemplary.
Run 3
The code is generally readable but has some minor issues. The structure is logical, with a clear setup phase followed by an assertion. Nesting is minimal with a single conditional block. Intent is mostly clear—testing recurrence behavior when a grandchild is completed. However, the method name is long and slightly ambiguous, and the conditional logic could be extracted for clarity. Code length is reasonable but could be slightly condensed. Action granularity is mostly one action per line, which is good. Reading flow is natural, though the inline conditional adds slight mental overhead. Overall, it's understandable but could benefit from minor refactoring for improved clarity.
Run 1
Code Structure: Logically organized into setup, completion action, expected-result calculation, and assertion. Nesting: Only one shallow conditional, making control flow easy to follow. Clarity of intent: The descriptive test name and variable names explain the scenario, though the completion-policy helper and recurrence behavior require external context. Code length: Short and focused, with no obvious unnecessary statements. Action granularity: Each statement performs one clear action; the assertion's chained method calls are straightforward. Reading flow: Progresses naturally from arranging the hierarchy to checking the parent's planned start time. Minor readability drawbacks are the long identifiers and lack of visual separation between setup and verification.
Run 2
Code Structure: The test follows a logical setup, action, expected-result calculation, and assertion sequence. Nesting: A single conditional keeps nesting shallow. Clarity of intent: The descriptive test name and variable names explain the behavior under test, although the helper's name leaves its potential side effects unclear. Code length: The code is concise, with no obvious unnecessary steps. Action granularity: Each statement performs one main action; the final assertion contains straightforward chained calls. Reading flow: Execution reads naturally from configuring recurrence to verifying the parent's planned start date. Long camelCase identifiers and the wrapped assertion slightly reduce scanability, while comparing ordinal values obscures why an approximate comparison is needed.
Run 3
Code Structure: Logically organized into setup, completion action, expected-result calculation, and assertion. Nesting: Only one shallow conditional, making control flow easy to follow. Clarity of intent: The descriptive test name and explicit method names communicate the scenario, though the conditional expected result and implicit parent-child setup require familiarity with the fixture. Code length: Concise, with no obvious unnecessary code. Action granularity: Each statement performs one primary action; the multiline assertion remains clear. Reading flow: Progresses naturally from arranging relationships to completing the grandchild and checking the parent's planned start date. Long camelCase identifiers and the lack of visual separation between test phases slightly reduce readability.