Sample
Dorn/python/55
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 57.1Δ 25.1 |
| Scalabrino | 0.541 | 0–1; higher is more readable | 49.6Δ 32.6 |
| Dorn | 0.852 | 0–1; higher is more readable | 86.1Δ 3.9 |
| Mi | 0.331 | 0–1; higher is more readable | 32.3Δ 49.9 |
| LLOC | 23 | Logical lines; fewer is more readable | 24.8Δ 57.4 |
| DeepSeek V4 Pro | 16.33 | 0–20; mean of three runs | 87.9Δ 5.7 |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs | 80.4Δ 1.8 |
| BTTF | 0.634 | 0–1; higher is more readable | 81.3Δ 0.8 |
| Human | 3.79 | 1–5; original rating | 82.2 |
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) |
|---|---|---|
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 896.271 | −29.577 |
| Source linesThe number of non-empty source lines. | 50 | +20 |
| 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.794 | −7.191 |
Intercept 8.87 + feature contributions = -7.898 (log-odds).
Score = sigmoid(-7.898) = 0.
| Score | 0.541 |
|---|
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. | 51 | −0.769 |
| 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. | 72.98 | +0.574 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.044 | +0.517 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 32 | +0.37 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 68.765 | +0.305 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 49.865 | +0.287 |
Intercept 0.07 + feature contributions = 1.752 (log-odds).
Score = sigmoid(1.752) = 0.852.
| Score | 0.331 |
|---|
| Score | 23 |
|---|
Run 1
The code demonstrates clear structure with logical class separation and a well-named utility function. Nesting is minimal, with only one level of indentation in the cleanup method. Intent is evident from descriptive names like TempFiles, register, cleanup, and get_temp_file. The code is concise without unnecessary verbosity. Each line performs a single logical action, maintaining good action granularity. Reading flow is natural—imports, class definition, then utility function. Minor deductions: the bare except in cleanup slightly obscures error intent, and the name-mangled __tempFiles could be simplified to _tempFiles following Python convention. Overall, highly readable with clean organization and clear purpose.
Run 2
The code is generally well-structured with clear separation of concerns: a Singleton class manages cleanup, and a helper function creates/registers temp files. Nesting is minimal and intent is clear. However, there are minor readability issues: the bare except (even with pylint disable) hides all exceptions, which can obscure debugging; the cleanup logic could be more explicit; and the module-level function lacks type hints or additional context. Action granularity is mostly one action per line, and the reading flow is natural. Overall, it is readable but not exemplary due to exception handling and slightly terse implementation.
Run 3
The code is reasonably readable: clear class and function names, a logical structure, and docstrings that explain intent. There is minimal nesting, and actions are mostly one per line. However, the broad `except: pass` block in `cleanup` hides errors, making the purpose slightly ambiguous. The `TempFiles` class is short and cohesive, but the use of `__metaclass__` and `__tempFiles` name mangling feels slightly dated. The `get_temp_file` function is concise and clear. Overall, the code is straightforward but could be improved by adding a comment explaining the Windows-specific chmod and by using a more specific exception handler.
Run 1
Code Structure: Well organized into a temporary-file registry class and a focused helper function. Nesting: Shallow overall, with a straightforward loop, try block, and platform-specific conditional. Clarity of intent: Descriptive method names and the helper docstring clearly explain file creation and cleanup; however, the bare exception handler silently hides failures, and the singleton metaclass requires external knowledge. Code length: Concise, with little unnecessary implementation code; the lengthy license header does not obscure the core logic significantly. Action granularity: Most lines perform one action, although imports are grouped on one line. Reading flow: Natural progression from imports to registry management to file creation, with consistent spacing and small methods. Minor formatting issues, such as missing spaces around the bitwise operator, slightly reduce polish.
Run 2
Code Structure: Logically separates temporary-file tracking and cleanup from file creation, though the singleton adds some implicit behavior. Nesting: Mostly flat, with modest nesting in the cleanup loop and platform-specific condition. Clarity of intent: Descriptive names and the function docstring clearly explain the purpose; the bare exception handler obscures which failures are intentionally ignored. Code length: Implementation is concise without unnecessary repetition; the lengthy license header does not complicate the logic. Action granularity: Statements generally perform one action per line, although multiple imports are grouped together. Reading flow: Initialization, registration, cleanup, and file creation follow naturally. Legacy metaclass syntax, inconsistent naming conventions, and tightly spaced bitwise operators slightly reduce readability.
Run 3
Code Structure: The cleanup registry and temporary-file creation helper are logically separated. Nesting: Depth is modest, with a loop, try block, and platform-specific conditional. Clarity of intent: Descriptive names and the helper docstring make the purpose clear, though the singleton metaclass and silent bare exception require inference. Code length: The implementation is concise; the lengthy license header does not complicate the logic. Action granularity: Most lines perform one action, although imports are combined on one line. Reading flow: Registration, creation, and cleanup follow naturally, with consistent spacing overall. Readability would improve with a comment explaining Windows permission changes, more explicit exception handling, and conventional spacing around the bitwise operator.