Source code
Official dataset source · Dorn/python/70
Sample
Dorn/python/70
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.996 | 0–1; higher is more readable | 97.8Δ 49.4 |
| Dorn | 0.945 | 0–1; higher is more readable | 98.1Δ 49.7 |
| Mi | 0.655 | 0–1; higher is more readable | 73.8Δ 25.5 |
| LLOC | 3 | Logical lines; fewer is more readable | 88.6Δ 40.3 |
| DeepSeek V4 Pro | 17.33 | 0–20; mean of three runs | 95.5Δ 47.2 |
| GPT-6.1 Sol | 19 | 0–20; mean of three runs | 98.9Δ 50.6 |
| BTTF | 0.765 | 0–1; higher is more readable | 96.1Δ 47.8 |
| Human | 3.33 | 1–5; original rating | 48.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.235 | −6.353 |
| 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. | 31.699 | −1.046 |
Intercept 8.87 + feature contributions = 5.471 (log-odds).
Score = sigmoid(5.471) = 0.996.
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. | 53 | +1.42 |
| 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.016 | +0.784 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 4 | −0.599 |
| 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. | 10 | −0.27 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 52.727 | +0.046 |
Intercept 0.07 + feature contributions = 2.851 (log-odds).
Score = sigmoid(2.851) = 0.945.
| Score | 0.655 |
|---|
| Score | 3 |
|---|
Run 1
The code is highly readable with clear structure and intent. It defines a simple exception class with a descriptive name and a docstring that includes a usage example. The nesting is minimal, and the code is concise with no unnecessary complexity. Each line serves a single purpose, and the reading flow is natural. The only minor drawback is the somewhat redundant docstring example, which slightly increases length without adding substantial value for such a trivial class.
Run 2
The code is concise and well-structured. It clearly defines a custom exception class inheriting from LockError, with a docstring that explains its purpose and provides a usage example. Indentation is minimal and flat. The action granularity is appropriate—one logical action per line. Reading flow is natural: class definition, docstring, then pass. Potential minor improvements could include adding more context about when the exception is raised, but the doctest example already demonstrates intent effectively.
Run 3
The code is highly readable. It defines a single purpose exception class with a clear, descriptive name. The docstring provides context and includes a simple usage example, which enhances understanding. The structure is flat, with no nesting or complexity. It is concise and each action is on its own line, contributing to a natural reading flow. The only minor deduction is the use of a bare 'pass' statement, which could be replaced with a docstring-only body for even cleaner code.
Run 1
Code Structure: A logically organized exception class with a descriptive docstring. Nesting: Minimal; the try/except appears only in the documentation example. Clarity of intent: The class name, LockError inheritance, and docstring clearly communicate a lock-conflict exception. Code length: Concise, with a short example demonstrating that LockError catches AlreadyLocked. Action granularity: Each statement occupies its own line. Reading flow: Natural progression from declaration to documentation to the empty body. The final pass is conventional but unnecessary because the docstring already supplies a valid class body.
Run 2
Code Structure: A simple, logically organized exception subclass with documentation followed by its empty body. Nesting: Minimal; the only nested control flow appears in the doctest. Clarity of intent: The class name, LockError inheritance, and docstring clearly identify a file-lock conflict. Code length: Concise, though the doctest adds a little length for a straightforward exception. Action granularity: Each statement occupies its own line. Reading flow: Natural progression from declaration to explanation, example, and pass. The doctest mainly demonstrates inheritance rather than the specific locking condition, slightly limiting its explanatory value.
Run 3
Code Structure: A logically organized exception class with its documentation directly beneath the declaration. Nesting: Minimal nesting; the try/except appears only in the docstring example. Clarity of intent: The class name, LockError inheritance, and docstring clearly communicate a file-lock conflict, though 'is locking' could more precisely describe an existing lock. Code length: Short and appropriate; the doctest adds useful context without excessive detail. Action granularity: Each declaration and example statement occupies its own line. Reading flow: Natural progression from class definition to explanation, usage example, and empty implementation.