Source code
Official dataset source · Dorn/python/21
Sample
Dorn/python/21
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.981 | 0–1; higher is more readable | 93.9Δ 6.1 |
| Dorn | 0.924 | 0–1; higher is more readable | 96.1Δ 3.9 |
| Mi | 0.759 | 0–1; higher is more readable | 93.9Δ 6.1 |
| LLOC | 3 | Logical lines; fewer is more readable | 88.6Δ 11.4 |
| DeepSeek V4 Pro | 18.67 | 0–20; mean of three runs | 99.9Δ 0.1 |
| GPT-6.1 Sol | 19.33 | 0–20; mean of three runs | 100.0Δ 0.0 |
| BTTF | 0.849 | 0–1; higher is more readable | 98.3Δ 1.7 |
| Human | 4.4 | 1–5; original rating | 100.0 |
Views
Select the downloaded ZIP or its extracted folder. Files stay in your browser.
Loading feature diagnosis…
Source regions
Feature contributions
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.864 | −7.295 |
| Source linesThe number of non-empty source lines. | 8 | +3.2 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 25.266 | −0.834 |
Intercept 8.87 + feature contributions = 3.941 (log-odds).
Score = sigmoid(3.941) = 0.981.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 1 | +1.001 |
| 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 | +0.954 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.009 | +0.857 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 1 | −0.703 |
| 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 | −0.298 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 63.667 | +0.223 |
Intercept 0.07 + feature contributions = 2.503 (log-odds).
Score = sigmoid(2.503) = 0.924.
| Score | 0.759 |
|---|
| Score | 3 |
|---|
Run 1
The code is exceptionally readable. It has a clear, logical structure with module metadata (docstring, author, license) presented in a standard order. There is no nesting or branching logic to evaluate. The intent is unambiguous: a docstring explains the module's purpose, and the metadata attributes are self-explanatory. The code is concise, containing no unnecessary lines. Each statement is a single, well-defined action on its own line. The reading flow is natural, following the conventional Python module header sequence.
Run 2
This code snippet is a well-structured module header. It includes a docstring with copyright and a brief description, followed by standard metadata variables (__author__, __license__). The structure is logical and clear, with no unnecessary nesting. Intent is explicit: to document ownership and licensing. It is concise, with each statement on its own line, and the reading flow is natural — starting with context, then authorship, then license. Some minor deductions are due to the copyright year range '2003-2010' being somewhat stale, and the docstring could be slightly more descriptive of the module's actual purpose, but overall it is highly readable.
Run 3
The code is highly readable. It has a clear, flat structure with no nesting or complex logic. The intent is unambiguous: it provides module metadata (copyright, author, license) and a concise docstring explaining the module's purpose. Code length is minimal and appropriate—no unnecessary verbosity. Each line performs a single, clear action (assigning metadata variables or stating the docstring). The reading flow is natural: a docstring first, followed by standard metadata assignments in a logical order. Minor deductions only because the docstring doesn't mention the actual extensions' APIs, but this is typical for legal/metadata headers and doesn't impact readability.
Run 1
Code Structure: A module docstring followed by author and license metadata is logically organized. Nesting: No nesting makes the snippet easy to scan. Clarity of intent: The docstring describes the module's purpose, and the metadata names are clear, though no implementation is shown. Code length: Very concise, with no unnecessary code. Action granularity: Each assignment occupies its own line. Reading flow: The description naturally precedes the metadata, producing a straightforward reading experience.
Run 2
Code Structure: The module docstring followed by author and license metadata is logically organized. Nesting: There is no nesting. Clarity of intent: The docstring states the module's purpose, and the metadata names are conventional and clear. Code length: The snippet is concise, with no unnecessary implementation detail. Action granularity: Each assignment occupies its own line. Reading flow: The sequence from module description to attribution and licensing is natural and easy to follow.
Run 3
Code Structure: Cleanly organized, with a module docstring followed by author and license metadata. Nesting: None, making the snippet easy to scan. Clarity of intent: The docstring clearly describes the module's intended purpose, and the metadata names are conventional, though no implementation is shown. Code length: Concise, with no unnecessary code. Action granularity: Each metadata assignment occupies its own line. Reading flow: Natural progression from copyright and module description to attribution and licensing.