Sample

Dorn/python/73

Human rating uses the original dataset scale.

DatasetDorn

Human3.35

Lines9

Scores

Method	Score	Scale	Dataset rank (0–100)
Posnett	0.989	0–1; higher is more readable	95.8Δ 44.8
Dorn	0.928	0–1; higher is more readable	96.9Δ 46.0
Mi	0.681	0–1; higher is more readable	78.6Δ 27.6
LLOC	4	Logical lines; fewer is more readable	82.7Δ 31.8
DeepSeek V4 Pro	14.67	0–20; mean of three runs	74.1Δ 23.1
GPT-6.1 Sol	11.67	0–20; mean of three runs	16.9Δ 34.1
BTTF	0.527	0–1; higher is more readable	52.4Δ 1.4
Human	3.35	1–5; original rating	51.0

Views

Download official ZIP ↗

Select the downloaded ZIP or its extracted folder. Files stay in your browser.

Source code

Official dataset source · Dorn/python/73

Loading feature diagnosis…

Source regions

Feature contributions

Feature	Value	Contribution (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.	3.94	−5.909
Source linesThe number of non-empty source lines.	9	+3.6
Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones.	62.907	−2.076

Intercept 8.87 + feature contributions = 4.485 (log-odds).
Score = sigmoid(4.485) = 0.989.

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.	58	+1.209
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.029	+0.659
Indentation frequencyHow rapidly indentation changes from line to line.	6	−0.53
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.	1	+0.398
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.	8.966	−0.285
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.	52.2	+0.038

Intercept 0.07 + feature contributions = 2.561 (log-odds).
Score = sigmoid(2.561) = 0.928.

Score	0.681

Score	4

Run 1

The code is a simple class with minimal functionality, which makes it easy to read in terms of structure and nesting. However, the docstring contains placeholder text ('blah blah') that is unhelpful and fails to clarify intent. The code length is very short, but it lacks meaningful implementation or comments. Action granularity is fine, but the reading flow is interrupted by the vague documentation. Overall, it is readable only because it contains almost nothing to read.

Run 2

The code is readable but too incomplete to score higher. It shows a clean class definition, clear naming, and a docstring explaining purpose, which indicates good clarity of intent and structure. The constructor is properly indented and has a docstring for its parameter, suggesting some documentation effort. However, the docstring content ('blah blah') is not meaningful, lowering clarity. There is essentially no logic, so nesting, action granularity, and code length cannot be fully evaluated. The reading flow is natural for a class stub. Overall it appears tidy and organized, but the lack of real implementation and vague placeholder text prevent a high readability score.

Run 3

The code is highly readable. It has a clear class definition, a docstring explaining its purpose, and an __init__ method with a parameter and a placeholder docstring. The structure is logical, nesting is flat, and intent is clear. It is concise and each action is on its own line. Reading flow is natural. Minor deductions: the docstring content is placeholder ('blah blah') and indentation of the docstring is slightly unusual, but this does not significantly harm readability.

Run 1

Code Structure: The class and constructor are logically organized, but the implementation is only a skeleton. Nesting: Shallow and easy to follow. Clarity of intent: The class docstring identifies a database connection object, but the generic name DB and placeholder constructor docstring do not explain how the connection is used. Code length: Brief, though excess blank space and an uninformative multiline docstring add little value. Action granularity: No lines combine multiple actions, but no actual initialization occurs. Reading flow: The class-to-constructor progression is natural; inconsistent spacing and docstring indentation reduce polish.

Run 2

Code Structure: The class and constructor are logically organized, but the implementation is only a stub. Nesting: Shallow and easy to follow. Clarity of intent: The class docstring identifies a database connection object, but the generic name DB and placeholder constructor documentation leave its behavior unclear. Code length: Very short, though extra blank lines and an uninformative multiline docstring add unnecessary space. Action granularity: Each declaration is on its own line; there are no operational statements to assess. Reading flow: The class-to-constructor sequence is natural, but inconsistent docstring indentation and missing spacing after the parameter comma reduce polish.

Run 3

Code Structure: The class and constructor are logically organized, but the constructor has no implementation beyond its docstring. Nesting: Minimal nesting makes the snippet easy to scan. Clarity of intent: The class docstring identifies a database connection object, but the generic name DB and placeholder constructor documentation do not explain how the connection is used. Code length: Very short, though blank lines and the multiline placeholder docstring add unnecessary space. Action granularity: No lines combine multiple actions, but there are no substantive actions to evaluate. Reading flow: The class-to-constructor progression is natural; missing spacing between parameters and inconsistent docstring indentation reduce polish.