Sample
Dorn/python/54
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 27.2Δ 11.6 |
| Scalabrino | 0.434 | 0–1; higher is more readable | 34.3Δ 18.7 |
| Dorn | 0.707 | 0–1; higher is more readable | 66.7Δ 51.1 |
| Mi | 0.397 | 0–1; higher is more readable | 38.3Δ 22.7 |
| LLOC | 21 | Logical lines; fewer is more readable | 29.7Δ 14.1 |
| DeepSeek V4 Pro | 9.33 | 0–20; mean of three runs | 37.2Δ 21.6 |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs | 66.0Δ 50.4 |
| BTTF | 0.549 | 0–1; higher is more readable | 59.2Δ 43.6 |
| Human | 2.63 | 1–5; original rating | 15.6 |
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. | 1119.389 | −36.94 |
| Source linesThe number of non-empty source lines. | 29 | +11.6 |
| 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.426 | −8.139 |
Intercept 8.87 + feature contributions = -24.609 (log-odds).
Score = sigmoid(-24.609) = 0.
| Score | 0.434 |
|---|
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. | 73.967 | +0.532 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 73.967 | +0.389 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 26 | −0.176 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 26 | +0.162 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.104 | −0.066 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 30 | −0.026 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 28.867 | −0.006 |
Intercept 0.07 + feature contributions = 0.88 (log-odds).
Score = sigmoid(0.88) = 0.707.
| Score | 0.397 |
|---|
| Score | 21 |
|---|
Run 1
The code is mostly readable due to flat structure, clear constants, and simple helper functions. However, it has some issues: inconsistent indentation (tabs vs spaces), misleading function naming in all-caps (suggesting constants), duplicate logic in the two functions, and mixed naming conventions. The functions are concise but could be refactored to reduce repetition. Overall intent is clear, but style inconsistencies and naming ambiguity lower readability.
Run 2
The code defines constants and helper functions for a wxPython scheduler. Structure is mostly flat and constants are grouped, but naming is inconsistent: uppercase constants with lowercase function-style definitions (e.g., SCHEDULER_BACKGROUND_BRUSH as a function with parentheses) and misleading comments ('Not actually a constant :)' adds ambiguity. Nesting is minimal, and each function performs one action, but the duplication of background color retrieval logic in both brush functions hurts readability. Alignment of assignments with mixed tabs/spaces is visually cluttered. Version and scheduling constants lack explanation, leaving intent unclear. The code is concise but not self-documenting; the overall reading flow feels disjointed due to style inconsistencies and unexplained constants.
Run 3
This code has serious readability issues. The structure is confusing: the comment 'Not actually a constant' explains a bad design choice, but the all-caps SCHEDULER_BACKGROUND_BRUSH() and DAY_BACKGROUND_BRUSH() function names look like constants. Both functions are nearly identical duplicated logic and should be refactored. The constant naming is inconsistent (SCHEDULER_BACKGROUND_BRUSH vs FOREGROUND_PEN vs wxSCHEDULER_DAILY). Mixing tabs and spaces in alignment is messy. The module imports and constants are flat, but the purpose of each value is unclear without context. The code is short but violates naming conventions and DRY principles, reducing clarity. However, the lowercase functions are at least simple and readable—they would be clearer if named get_scheduler_background_brush() and get_day_background_brush(). Overall, it's a poorly structured snippet that needs refactoring.
Run 1
Code Structure: Constants are logically grouped, followed by two small color helpers, but the final pen constant interrupts that organization. Nesting: Flat code with no nested control flow is easy to scan. Clarity of intent: Descriptive constant names and straightforward color calculations communicate purpose, although BRUSH-named functions return colors and abbreviated local names reduce precision. Code length: Compact overall, with minor repetition in retrieving and extracting the background color. Action granularity: Most lines perform one action; RGB extraction groups three closely related operations on one line. Reading flow: Generally natural, but inconsistent alignment, spacing inside parentheses, and missing blank lines between functions weaken visual separation.
Run 2
Code Structure: Constants and color helper functions are logically grouped, but the trailing pen constant and limited spacing between functions weaken organization. Nesting: The code is flat, with no nested control flow. Clarity of intent: Scheduler constants and color calculations are understandable, though BRUSH-named functions return colors, and abbreviated local names offer little context. Code length: Short overall, with minor duplication in retrieving and unpacking the system color. Action granularity: Most lines perform one assignment or return; tuple unpacking and inline color adjustments remain easy to follow. Reading flow: Generally natural, but inconsistent tabs, alignment, capitalization conventions, and missing blank lines between definitions make scanning less smooth.
Run 3
Code Structure: Constants and two small color helpers are logically grouped, but missing blank lines between functions and the final constant weaken separation. Nesting: No nested control flow, making the code easy to follow. Clarity of intent: Descriptive scheduler constants and straightforward color calculations communicate purpose, although BRUSH-named functions return colors and abbreviated variables slightly obscure meaning. Code length: Compact overall, with minor duplication in retrieving system colors. Action granularity: Most lines perform one action; RGB tuple assignments combine three related method calls without becoming difficult to read. Reading flow: The progression from imports to constants to helpers is natural, but inconsistent spacing, tab alignment, and the trailing constant reduce visual consistency.