Sample

Dorn/python/27

Human rating uses the original dataset scale.

DatasetDorn

Human4.16

Lines10

Scores

Method	Score	Scale	Dataset rank (0–100)
Posnett	0.014	0–1; higher is more readable	69.1Δ 27.6
Dorn	0.994	0–1; higher is more readable	98.9Δ 2.2
Mi	0.632	0–1; higher is more readable	68.2Δ 28.4
LLOC	1	Logical lines; fewer is more readable	97.9Δ 1.3
DeepSeek V4 Pro	16.33	0–20; mean of three runs	87.9Δ 8.8
GPT-6.1 Sol	18.67	0–20; mean of three runs	97.6Δ 1.0
BTTF	0.863	0–1; higher is more readable	99.4Δ 2.8
Human	4.16	1–5; original rating	96.7

Views

Download official ZIP ↗

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

Source code

Official dataset source · Dorn/python/27

Loading feature diagnosis…

Source regions

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.	290.697	−9.593
Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value.	5.007	−7.51
Source linesThe number of non-empty source lines.	10	+4

Intercept 8.87 + feature contributions = -4.233 (log-odds).
Score = sigmoid(-4.233) = 0.014.

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.	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
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
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.	59.091	+0.149

Intercept 0.07 + feature contributions = 5.113 (log-odds).
Score = sigmoid(5.113) = 0.994.

Score	0.632

Score	1

Run 1

The code is a docstring-only module with clear structure and minimal content. It has no nesting, excellent action granularity (one logical block), and clear intent (a ConTeXt front end for Docutils). However, it is more of a placeholder than functional code, so it lacks the complexity that would demonstrate readability in a real implementation. The metadata comments are informative, and reading flow is natural. The score reflects that while it is concise and unambiguous, there is little code to evaluate.

Run 2

The code is a concise module docstring with standard metadata comments. It is highly readable due to its logical structure (metadata, then docstring), flat structure with no nesting, clear intent, brevity, and natural reading flow. It lacks any executable code, so granularity is excellent by default.

Run 3

The code is minimal but highly readable due to its clear structure and intent. It follows a conventional file header format with author, contact, revision, date, and copyright, separated logically. The use of a docstring to describe the module's purpose is concise and effective. There is no nesting, excessive length, or ambiguity. Each line serves a single purpose, and the reading flow is natural from metadata to documentation. The only minor deduction is that the code is a stub with no functional logic, but as presented it adheres well to readability principles.

Run 1

Code Structure: Metadata is cleanly separated from the module docstring. Nesting: None, making the snippet easy to scan. Clarity of intent: The docstring clearly identifies the module as a minimal Docutils front end producing ConTeXt, though no implementation is shown. Code length: Very concise; the metadata adds modest nonfunctional length. Action granularity: Each metadata item occupies its own line, and there are no compound statements. Reading flow: Natural progression from authorship and licensing information to the module's purpose. The score reflects the readability of this documentation-only snippet, not the absent implementation.

Run 2

Code Structure: The author metadata is grouped together, followed by a module docstring, giving the snippet a logical organization. Nesting: There is no nesting. Clarity of intent: The docstring clearly states that the module is a minimal Docutils front end producing ConTeXt, though no implementation is shown. Code length: The snippet is concise, with only a small amount of metadata overhead. Action granularity: Each metadata item occupies its own line; there are no executable actions to assess. Reading flow: The progression from attribution to purpose is natural and easy to scan. Readability is high, but the absence of executable code limits assessment of implementation readability.

Run 3

Code Structure: Clearly separates author metadata from the module description. Nesting: None, making it effortless to scan. Clarity of intent: The docstring directly states the module's purpose, although no implementation is shown. Code length: Very concise; revision and date metadata add minor clutter. Action granularity: No executable actions are present, and each metadata item occupies its own line. Reading flow: Natural progression from attribution to purpose. This rating applies only to the provided header and docstring, not to any unseen implementation.