Sample
Dorn/python/34
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 40.4Δ 52.9 |
| Dorn | 0.839 | 0–1; higher is more readable | 83.6Δ 9.7 |
| Mi | 0.64 | 0–1; higher is more readable | 70.2Δ 23.1 |
| LLOC | 19 | Logical lines; fewer is more readable | 35.5Δ 57.8 |
| DeepSeek V4 Pro | 17.33 | 0–20; mean of three runs | 95.5Δ 2.2 |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs | 93.5Δ 0.1 |
| BTTF | 0.641 | 0–1; higher is more readable | 83.3Δ 10.0 |
| Human | 4.05 | 1–5; original rating | 93.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) |
|---|---|---|
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 899.284 | −29.676 |
| Source linesThe number of non-empty source lines. | 30 | +12 |
| 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.521 | −6.782 |
Intercept 8.87 + feature contributions = -15.588 (log-odds).
Score = sigmoid(-15.588) = 0.
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. | 69.968 | +0.702 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 67.806 | +0.29 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.074 | +0.223 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 20 | −0.045 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 29 | +0.01 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 29.507 | +0.003 |
Intercept 0.07 + feature contributions = 1.649 (log-odds).
Score = sigmoid(1.649) = 0.839.
| Score | 0.64 |
|---|
| Score | 19 |
|---|
Run 1
The code is generally clear and well-structured. Functions are small and focused, with docstrings explaining intent. Nesting is flat, and action granularity is mostly one operation per line, aiding readability. However, minor issues prevent a higher score: escape() mutates its input across multiple lines but is simple enough; escape_arg() and escape_id() have slight repetition in whitespace normalization. The placeholder comment in escape() about em dashes is somewhat ambiguous. Overall, the code is concise, logical, and easy to follow.
Run 2
The code is highly readable due to its clear, modular structure with three small, single-purpose functions. Each function has a descriptive docstring explaining its intent, and the logic flows naturally. Action granularity is excellent, with one operation per line, and nesting is essentially flat. Variable names like 'bad_chars' are descriptive, and the code is concise without being cryptic. Minor deductions: the commented-out line could be removed for cleanliness, and escape_arg/escape_id share some normalization logic that could potentially be factored out, but this does not significantly impact readability.
Run 3
The code is highly readable due to its clear logical structure, flat organization, and concise length. Each function has a single, well-defined purpose with descriptive names and docstrings that clearly state intent. It follows a flat, non-nested structure with minimal indentation, making the control flow easy to follow. Action granularity is strong, with one replace or transform operation per line for escape and escape_arg, while escape_id uses a simple loop for clarity. Reading flow is natural and straightforward. Minor improvements could be made by avoiding repeated reassignment in escape(), but this is not a significant issue. Overall, the code is exemplary in readability.
Run 1
Code Structure: Three focused functions logically separate general escaping, argument escaping, and identifier sanitization. Nesting: Nearly flat, with only a simple loop in escape_id. Clarity of intent: Descriptive function names and docstrings explain the purpose; abbreviated variables s and bc, an orphaned opening comment, and commented-out code slightly reduce clarity. Code length: Concise overall, although strip() is redundant after joining split() results. Action granularity: Each statement performs one clear transformation. Reading flow: Sequential replacements and normalization are easy to follow, and escape_arg naturally builds on escape. Minor comment spelling and formatting issues do not significantly hinder readability.
Run 2
Code Structure: Three small, logically separated functions organize related escaping tasks, with escape_arg reusing escape. Nesting: Almost entirely flat, with only one simple loop. Clarity of intent: Descriptive function names and docstrings clearly explain each purpose; the vague variable bc, stray opening comment, and commented-out replacement slightly reduce clarity. Code length: Concise overall, although strip() is redundant after joining split() results. Action granularity: Each statement performs a focused transformation, making changes easy to track. Reading flow: Sequential replacements and whitespace normalization read naturally, with consistent formatting. Minor comment issues, including the typo 'delimeters' and unused em-dash handling, introduce small distractions.
Run 3
Code Structure: Three small, logically separated functions handle distinct escaping needs, with escape_arg reusing escape. Nesting: Nearly flat, with only a simple loop in escape_id. Clarity of intent: Descriptive function names and docstrings clearly explain purposes; s and bc are somewhat terse, and the opening comment is incomplete. Code length: Concise overall, though strip() after split/join is redundant and the disabled replacement adds clutter. Action granularity: Each line generally performs one clear transformation; whitespace normalization compactly combines related operations. Reading flow: Straightforward top-to-bottom transformations and consistent formatting make the code easy to follow. Minor comment issues, including a spelling error, slightly reduce polish.