Source code
Official dataset source · Dorn/python/52
Sample
Dorn/python/52
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.504 | 0–1; higher is more readable | 82.2Δ 8.1 |
| Dorn | 0.583 | 0–1; higher is more readable | 50.7Δ 39.6 |
| Mi | 0.326 | 0–1; higher is more readable | 31.8Δ 58.5 |
| LLOC | 6 | Logical lines; fewer is more readable | 72.8Δ 17.4 |
| DeepSeek V4 Pro | 14 | 0–20; mean of three runs | 65.9Δ 24.4 |
| GPT-6.1 Sol | 17.67 | 0–20; mean of three runs | 88.9Δ 1.4 |
| BTTF | 0.684 | 0–1; higher is more readable | 89.7Δ 0.6 |
| Human | 3.94 | 1–5; original rating | 90.3 |
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.586 | −6.878 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 181.11 | −5.977 |
| Source linesThe number of non-empty source lines. | 10 | +4 |
Intercept 8.87 + feature contributions = 0.015 (log-odds).
Score = sigmoid(0.015) = 0.504.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| 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 |
| 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. | 75 | +0.489 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.055 | +0.407 |
| 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.737 | −0.274 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 10 | +0.191 |
Intercept 0.07 + feature contributions = 0.335 (log-odds).
Score = sigmoid(0.335) = 0.583.
| Score | 0.326 |
|---|
| Score | 6 |
|---|
Run 1
The code is concise and logically structured, but readability suffers due to ambiguous context (dbapi20 not imported), minimal explanation of test purpose, and dense argument packing in connect_kw_args.
Run 2
The code is concise and demonstrates clear intent, but it has significant readability issues. It lacks proper structure: the class inherits from dbapi20.DatabaseAPI20Test, which is not imported, making the code incomplete and potentially confusing. There is no explanation of the test setup or why these specific connection arguments are used, which reduces clarity. Nesting is minimal and reading flow is natural, but the absence of imports and context lowers the score. The code is not unnecessarily long, and action granularity is appropriate since each argument is on its own line. However, the missing import and unexplained configuration prevent it from being highly readable.
Run 3
The code is generally readable: it has a clear purpose (setting up an abstract test class for MySQLdb), uses flat structure, and keeps each argument on its own line. However, the class name violates PEP 8 conventions (should be CamelCase, not lowercase with underscores), and it references an undefined base class `dbapi20.DatabaseAPI20Test`, making intent ambiguous without context. The lack of a docstring or comment explaining the test configuration reduces clarity. Overall, it is concise and well-structured but could improve with naming consistency and explanatory comments.
Run 1
Code Structure: Imports and a single configuration-focused test class are logically organized. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: The class name and connection settings clearly indicate MySQL database API testing, though dbapi20 is referenced without an import and the database name is generic. Code length: Concise, with no unnecessary logic. Action granularity: Each assignment has a distinct purpose, and connection options are separated across lines. Reading flow: Natural top-to-bottom progression, although inconsistent continuation indentation, nonstandard class naming, and the apparently unused unittest import slightly reduce readability.
Run 2
Code Structure: Imports followed by a small test class provide logical organization, though dbapi20 is referenced without a visible import. Nesting: Minimal, with only class-level indentation and a multiline dictionary. Clarity of intent: The class clearly configures MySQL database API tests; the unconventional class name slightly reduces polish. Code length: Concise, with no unnecessary logic. Action granularity: Each assignment has a single purpose, and connection options appear on separate lines. Reading flow: Natural top-to-bottom progression from dependencies to driver and connection configuration; slightly uneven continuation indentation is a minor distraction.
Run 3
Code Structure: Imports and test configuration are logically organized within a single class. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: The class clearly configures MySQL database API tests, although dbapi20 is referenced without an import, and the class name uses unconventional capitalization. Code length: The snippet is concise, with no unnecessary code. Action granularity: Each configuration assignment occupies its own logical statement, and dictionary options are separated across lines. Reading flow: The sequence from imports to driver and connection settings is natural; slightly inconsistent continuation indentation mildly reduces readability.