Sample
Dorn/python/38
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 52.4Δ 8.4 |
| Dorn | 0.881 | 0–1; higher is more readable | 93.0Δ 49.0 |
| Mi | 0.558 | 0–1; higher is more readable | 58.5Δ 14.5 |
| LLOC | 10 | Logical lines; fewer is more readable | 59.5Δ 15.5 |
| DeepSeek V4 Pro | 14.67 | 0–20; mean of three runs | 74.1Δ 30.1 |
| GPT-6.1 Sol | 16.33 | 0–20; mean of three runs | 70.8Δ 26.7 |
| BTTF | 0.667 | 0–1; higher is more readable | 88.9Δ 44.8 |
| Human | 3.25 | 1–5; original rating | 44.0 |
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. | 681.796 | −22.499 |
| Source linesThe number of non-empty source lines. | 29 | +11.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.899 | −7.348 |
Intercept 8.87 + feature contributions = -9.377 (log-odds).
Score = sigmoid(-9.377) = 0.
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. | 64.933 | +0.915 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.043 | +0.526 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 60.733 | +0.175 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 20 | −0.045 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 30 | −0.026 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 28.773 | −0.008 |
Intercept 0.07 + feature contributions = 2.006 (log-odds).
Score = sigmoid(2.006) = 0.881.
| Score | 0.558 |
|---|
| Score | 10 |
|---|
Run 1
The code is generally clear and well-structured with a simple, logical flow. It uses a modular layout with separate functions and variables, which aids readability. Nesting is minimal, with only one conditional block at the end. Intent is evident through the docstring and function naming. Code length is concise and appropriate for the task. Each line generally represents one action, and the reading flow is natural: imports, function definition, test data assignment, and the main block. Minor deductions are due to the lack of comments explaining the custom `DocutilsTestSupport` usage and the somewhat opaque `totest` variable name, which could be more descriptive.
Run 2
The code is generally clear but has some structural choices that reduce readability. The suite() function is concise and the action granularity is good, but the test data structure is not immediately obvious—the totest dictionary and nested list format lack comments or named constants to clarify intent. The triple-quoted strings and escaped line continuations make the test cases harder to scan. The module docstring and metadata comments provide context, but the overall organization could be improved by separating test data from test execution logic or adding a brief comment explaining the structure. The reading flow is natural at the top but becomes dense in the totest definition.
Run 3
The code is generally readable with clear structure and low nesting. The function 'suite' is concise and has a clear purpose. However, there are issues: variable name 's' is ambiguous, the 'totest' variable is declared after its use in the function which hurts the natural reading flow, and there's no spacing between functions/assignments which reduces visual organization. The test data structure with nested lists and escaped quotes is somewhat dense and could be clearer with named variables or constants. The module docstring is good, but the commented-out SVN metadata is outdated clutter. Action granularity is good with one action per line. Overall, it's readable but could benefit from minor improvements in naming, ordering, and spacing.
Run 1
Code Structure: The module logically separates imports, suite construction, and test data, though the empty main block appears unfinished. Nesting: Minimal nesting makes it easy to follow. Clarity of intent: The docstring and directive example clearly identify the test's purpose, but generic names such as s and totest reduce precision. Code length: Compact overall, with a slightly unnecessary two-step dictionary initialization. Action granularity: Each executable statement performs one action; multiline strings appropriately represent test input and expected output. Reading flow: Mostly natural, but placing test data after the suite function requires looking ahead, and the minimally indented nested list makes the input/output pairing less visually clear.
Run 2
Code Structure: Clearly separates imports, suite construction, test data, and the main guard, though the main block imports unittest without running tests. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: The docstring and test fixture clearly identify the title directive being tested; generic names such as s and totest are less descriptive. Code length: Short and focused, with little unnecessary code beyond the ineffective main block. Action granularity: Each executable statement performs one action. Reading flow: Mostly natural, but inconsistent indentation in the nested test list and defining test data after the suite function slightly reduce readability.
Run 3
Code Structure: Clearly separates imports, suite creation, and test data, though the main guard only imports unittest and appears incomplete. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: The docstring and explicit input/output fixture clearly identify a title-directive test, but generic names such as s and totest reduce clarity. Code length: Concise, with little unnecessary code. Action granularity: Each statement performs a single action. Reading flow: Mostly natural, although the test-list formatting is awkward, the import from __init__ is unconventional, and the unfinished main block leaves execution behavior unclear.