Sample

Dorn/python/34

Human rating uses the original dataset scale.

DatasetDorn
Human4.05
Lines30

Scores

MethodScoreScaleDataset rank
(0–100)
Posnett00–1; higher is more readable
40.4Δ 52.9
Dorn0.8390–1; higher is more readable
83.6Δ 9.7
Mi0.640–1; higher is more readable
70.2Δ 23.1
LLOC19Logical lines; fewer is more readable
35.5Δ 57.8
DeepSeek V4 Pro17.330–20; mean of three runs
95.5Δ 2.2
GPT-6.1 Sol180–20; mean of three runs
93.5Δ 0.1
BTTF0.6410–1; higher is more readable
83.3Δ 10.0
Human4.051–5; original rating
93.3

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

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

Score0.64
Score19
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.