Sample

Dorn/python/92

Human rating uses the original dataset scale.

DatasetDorn

Human4.16

Lines10

Scores

Method	Score	Scale	Dataset rank (0–100)
Posnett	0.93	0–1; higher is more readable	90.3Δ 7.0
Dorn	0.808	0–1; higher is more readable	78.3Δ 18.9
Mi	0.643	0–1; higher is more readable	71.6Δ 25.6
LLOC	6	Logical lines; fewer is more readable	72.8Δ 24.4
DeepSeek V4 Pro	16.67	0–20; mean of three runs	91.4Δ 5.8
GPT-6.1 Sol	18	0–20; mean of three runs	93.5Δ 3.8
BTTF	0.697	0–1; higher is more readable	91.6Δ 5.6
Human	4.16	1–5; original rating	97.2

Views

Download official ZIP ↗

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

Source code

Official dataset source · Dorn/python/92

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

Intercept 8.87 + feature contributions = 2.581 (log-odds).
Score = sigmoid(2.581) = 0.93.

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.	54	+1.378
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
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.	0.034	+0.614
Indentation frequencyHow rapidly indentation changes from line to line.	10	−0.391
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.	9.945	−0.271
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.	10	+0.191

Intercept 0.07 + feature contributions = 1.434 (log-odds).
Score = sigmoid(1.434) = 0.808.

Score	0.643

Score	6

Run 1

The code is highly readable. It has a clear logical structure with a simple purpose, minimal nesting, and concise length. The intent is evident from the docstring and import handling. The try/except block is properly indented and avoids deep nesting. One minor stylistic issue is the use of the Python 2 style print statement, which could be ambiguous or fail in Python 3. Action granularity and reading flow are natural, with one action per meaningful line.

Run 2

The code is clear and concise. It has a logical structure: docstring, import, then Scribus-specific import with error handling. Nesting is flat, with only a single try/except. Intent is obvious from the docstring. Length is minimal and appropriate. Each action (import, print, exit) is on its own line. The reading flow is natural, moving from purpose to dependency to execution context. The only minor readability concern is the import of all Scribus symbols ('*'), which can obscure which functions are used, and the use of Python 2-style print statement.

Run 3

The code is highly readable. It has a clear structure with a descriptive module docstring, a single import attempt, and a straightforward guard clause for environment validation. Nesting is minimal — only one try/except with no deeper levels. Intent is unambiguous: ensure the script runs inside Scribus or exit cleanly. Code length is concise with no redundancy. The action granularity is appropriate: imports and print/exit statements are separated for clarity. Reading flow is natural, progressing from documentation to import to validation. Minor deductions: using 'print' as a statement (Python 2 style rather than function) and the wildcard import slightly reduce modern clarity, but within the Scribus context, these are conventional and acceptable.

Run 1

Code Structure: Imports and error handling are logically organized. Nesting: A single try/except keeps the code flat and easy to follow. Clarity of intent: The Scribus dependency check is clear, but the docstring promises crop-mark drawing that is absent from the snippet, and the wildcard import obscures imported names. Code length: Brief, with no unnecessary code. Action granularity: Each statement performs one action on its own line. Reading flow: Natural progression from description to imports to dependency failure handling. Python 2 print syntax slightly reduces accessibility for modern readers.

Run 2

Code Structure: Logically organized into a brief description, imports, and import-failure handling. Nesting: A single try/except keeps nesting minimal. Clarity of intent: The Scribus dependency check is clear, but the docstring promises crop-mark functionality not present in this snippet, and the wildcard import obscures imported names. Code length: Concise, with no unnecessary statements. Action granularity: Each statement performs one action. Reading flow: Natural progression from setup to a clear error message and exit. Python 2 print syntax dates the code but remains understandable.

Run 3

Code Structure: Logically organized with a purpose docstring, import, and guarded Scribus import. Nesting: Minimal, with only a straightforward try/except block. Clarity of intent: The environment check and failure handling are clear, but the stated crop-mark functionality is absent, and the wildcard import obscures dependencies. Code length: Concise, without unnecessary code. Action granularity: Each statement performs one action on its own line. Reading flow: Natural progression from description to dependency loading and graceful termination. Python 2 print syntax slightly reduces readability for modern Python readers.