Sample

Dorn/python/38

Human rating uses the original dataset scale.

DatasetDorn
Human3.25
Lines29

Scores

MethodScoreScaleDataset rank
(0–100)
Posnett00–1; higher is more readable
52.4Δ 8.4
Dorn0.8810–1; higher is more readable
93.0Δ 49.0
Mi0.5580–1; higher is more readable
58.5Δ 14.5
LLOC10Logical lines; fewer is more readable
59.5Δ 15.5
DeepSeek V4 Pro14.670–20; mean of three runs
74.1Δ 30.1
GPT-6.1 Sol16.330–20; mean of three runs
70.8Δ 26.7
BTTF0.6670–1; higher is more readable
88.9Δ 44.8
Human3.251–5; original rating
44.0

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.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

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.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.

Score0.558
Score10
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.