Sample

Dorn/python/55

Human rating uses the original dataset scale.

DatasetDorn
Human3.79
Lines50

Scores

MethodScoreScaleDataset rank
(0–100)
Posnett00–1; higher is more readable
57.1Δ 25.1
Scalabrino0.5410–1; higher is more readable
49.6Δ 32.6
Dorn0.8520–1; higher is more readable
86.1Δ 3.9
Mi0.3310–1; higher is more readable
32.3Δ 49.9
LLOC23Logical lines; fewer is more readable
24.8Δ 57.4
DeepSeek V4 Pro16.330–20; mean of three runs
87.9Δ 5.7
GPT-6.1 Sol170–20; mean of three runs
80.4Δ 1.8
BTTF0.6340–1; higher is more readable
81.3Δ 0.8
Human3.791–5; original rating
82.2

Views

Download official ZIP ↗

Select the downloaded ZIP or its extracted folder. Files stay in your browser.

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(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.

Score0.541

Feature contributions

FeatureValueContribution
(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.

Score0.331
Score23
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.