Source code
Official dataset source · Dorn/python/11
Sample
Dorn/python/11
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.995 | 0–1; higher is more readable | 97.2Δ 1.4 |
| Dorn | 0.995 | 0–1; higher is more readable | 99.4Δ 3.6 |
| Mi | 0.744 | 0–1; higher is more readable | 92.2Δ 3.6 |
| LLOC | 1 | Logical lines; fewer is more readable | 97.9Δ 2.1 |
| DeepSeek V4 Pro | 14 | 0–20; mean of three runs | 65.9Δ 29.9 |
| GPT-6.1 Sol | 18.33 | 0–20; mean of three runs | 97.1Δ 1.3 |
| BTTF | 0.853 | 0–1; higher is more readable | 98.6Δ 2.8 |
| Human | 4.15 | 1–5; original rating | 95.8 |
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. | 5.01 | −7.516 |
| 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. | 3 | −0.099 |
Intercept 8.87 + feature contributions = 5.255 (log-odds).
Score = sigmoid(5.255) = 0.995.
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 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 76 | +0.422 |
| 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.386 (log-odds).
Score = sigmoid(5.386) = 0.995.
| Score | 0.744 |
|---|
| Score | 1 |
|---|
Run 1
The code is a docstring-only module with no executable logic, making it impossible to assess most readability criteria like structure, nesting, or action granularity. It consists of metadata and a brief description, which are clear but lack any substantive code to evaluate. The docstring is well-formatted and its intent is understandable, but the absence of implementation means it cannot be considered highly readable as a code sample. It is essentially an empty shell, so it scores low on practical readability for software evaluation purposes.
Run 2
The code is a well-structured module docstring containing standard metadata (author, contact, revision, date, copyright) and a clear one-line description of purpose. It is flat, unambiguous, concise, and follows a natural reading flow with zero unnecessary complexity. All actions and information are presented one per logical line, making it highly readable.
Run 3
The code is a metadata-only module docstring with clear structure: authorship, contact, revision, date, copyright, and a concise purpose statement. It is flat, with no nesting or control flow, and each piece of information is on its own line, showing excellent action granularity and reading flow. Intent is explicit—declaring a minimal PDF front-end for Docutils. The only deduction is that, as a functional module, it lacks executable content, but for documentation metadata alone it is highly readable and well-organized.
Run 1
Code Structure: The single module docstring is logically organized, separating metadata from the purpose statement. Nesting: There is no nesting. Clarity of intent: The description clearly identifies the intended Docutils-to-PDF functionality, though no implementation is provided. Code length: The excerpt is concise; the historical metadata adds minor reading overhead. Action granularity: There are no executable actions, and each metadata field occupies its own line. Reading flow: Consistent formatting and a blank line before the description make the text easy to scan. This score reflects the readability of the provided documentation, not an unseen implementation.
Run 2
Code Structure: A single module docstring logically groups metadata and a purpose statement. Nesting: None, so the snippet is easy to scan. Clarity of intent: The description clearly identifies a Docutils front-end producing PDF via ReportLabs, though no implementation is shown. Code length: Brief, with only a small amount of revision metadata that adds visual clutter. Action granularity: No executable actions; each metadata field occupies its own line. Reading flow: Consistent formatting and a blank line separating metadata from the description create a natural flow. This score applies only to the readability of the supplied documentation, not to any unseen implementation.
Run 3
Code Structure: A single, well-organized module docstring separates metadata from the purpose statement. Nesting: None, making it easy to scan. Clarity of intent: Clearly describes a minimal Docutils front-end producing PDF via ReportLabs, although no implementation is shown. Code length: Brief, with modest metadata overhead. Action granularity: No executable actions; each metadata field occupies its own line. Reading flow: Natural progression from authorship and version information to the module's purpose. The text is highly readable, but the absence of executable code limits assessment of implementation readability.