Sample

Dorn/python/57

Human rating uses the original dataset scale.

DatasetDorn
Human3.73
Lines10

Scores

MethodScoreScaleDataset rank
(0–100)
Posnett0.6960–1; higher is more readable
83.6Δ 5.0
Scalabrino0.5240–1; higher is more readable
46.5Δ 32.0
Dorn0.9960–1; higher is more readable
100.0Δ 21.4
Mi0.8370–1; higher is more readable
99.4Δ 20.9
LLOC6Logical lines; fewer is more readable
72.8Δ 5.7
DeepSeek V4 Pro120–20; mean of three runs
53.6Δ 24.9
GPT-6.1 Sol13.670–20; mean of three runs
37.7Δ 40.8
BTTF0.6640–1; higher is more readable
88.0Δ 9.5
Human3.731–5; original rating
78.6

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)
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.497−6.746
Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones.160.54−5.298
Source linesThe number of non-empty source lines.10+4

Intercept 8.87 + feature contributions = 0.827 (log-odds).
Score = sigmoid(0.827) = 0.696.

Score0.524

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.0+3.665
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.1+1.001
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0+0.942
Indentation frequencyHow rapidly indentation changes from line to line.1−0.703
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.81.909+0.517
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.0−0.41
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398

Intercept 0.07 + feature contributions = 5.481 (log-odds).
Score = sigmoid(5.481) = 0.996.

Score0.837
Score6
Run 1

The code is minimal but severely lacks context and meaningful naming. The module docstring is empty, providing no explanation of purpose. The function suite() is not clearly named, and its reliance on globals (DocutilsTestSupport, totest) obscures data flow. The variable 's' is cryptic and reused, while 'suite_settings' and 'generateTests' add some clarity but not enough. The code is concise and flat, but its brevity does not compensate for ambiguous intent and poor readability. It reads more like a scaffolding script than intended production logic. Overall, difficult to understand at a glance.

Run 2

The code is highly readable. It has a clear logical structure with a single function that sets up and returns a test suite. Nesting is minimal to none. The intent is straightforward—create a French language parser test suite. Code length is concise and not unnecessarily long. Each action is cleanly separated into single lines. The reading flow is natural, from function definition to setup, test generation, and return. The only minor deduction is the module-level `totest` dictionary defined after the function, which slightly disrupts conventional top-to-bottom reading order, but this is common in test-support patterns.

Run 3

The code is short and each action is on its own line, yielding good action granularity and reading flow. Nesting is minimal (just a function and dictionary), and the intent—to set up a test suite with French language settings—is fairly clear. However, readability suffers due to missing context: 'DocutilsTestSupport', 'totest', and 'suite_settings' are not defined in the snippet, making the logic ambiguous without external files. The empty module docstring and 'totest = {}' placed after the function also disrupt logical organization. Overall, the structure is straightforward but incomplete context limits clarity.

Run 1

Code Structure: The suite factory and test-data dictionary are logically separated, although defining totest before suite would make the dependency clearer. Nesting: Flat and easy to follow. Clarity of intent: ParserTestSuite and generateTests communicate the testing purpose, but s and totest are vague names. The leading, unclosed triple quote makes the snippet invalid as shown and obscures whether the following lines are intended as code or text. Code length: Concise, with no unnecessary logic. Action granularity: Each statement performs one clear action. Reading flow: Mostly natural, though the unexplained opening quote and reference to a later-defined dictionary interrupt comprehension.

Run 2

Code Structure: The intended organization is simple: import support, define a suite factory, and initialize test data. However, the opening triple quote is unclosed, making the snippet invalid Python as shown and obscuring whether it is code or documentation. Nesting: Only one indentation level, so it is easy to follow. Clarity of intent: The suite creation and test generation are understandable, but names such as 's' and 'totest' are vague, and the empty test dictionary provides little context. Code length: Concise, with no unnecessary logic. Action granularity: Each statement performs a single main action. Reading flow: Mostly natural, although defining 'totest' before the function would make its dependency easier to discover. More descriptive names and conventional spacing in the settings dictionary would improve readability.

Run 3

Code Structure: The intended import, suite factory, and test dictionary are logically organized, though the opening triple quote is unterminated and prevents parsing. Nesting: Only one function level, making the snippet easy to follow. Clarity of intent: Creating a French-language parser test suite is clear, but 's' and 'totest' are vague names, and the empty dictionary leaves test coverage unclear. Code length: Concise without unnecessary statements. Action granularity: Each statement performs one action. Reading flow: Mostly natural, though defining 'totest' before the function would make its dependency more immediately visible; inconsistent spacing and the stray triple quote reduce readability.