Sample
Dorn/python/33
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 54.6Δ 5.3 |
| Scalabrino | 0.519 | 0–1; higher is more readable | 45.7Δ 3.6 |
| Dorn | 0.533 | 0–1; higher is more readable | 45.7Δ 3.6 |
| Mi | 0.452 | 0–1; higher is more readable | 44.8Δ 4.5 |
| LLOC | 8 | Logical lines; fewer is more readable | 63.9Δ 14.6 |
| DeepSeek V4 Pro | 15.67 | 0–20; mean of three runs | 82.6Δ 33.3 |
| GPT-6.1 Sol | 17.67 | 0–20; mean of three runs | 88.9Δ 39.6 |
| BTTF | 0.49 | 0–1; higher is more readable | 42.3Δ 7.0 |
| Human | 3.34 | 1–5; original rating | 49.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. | 442.804 | −14.613 |
| 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.476 | −6.714 |
| Source linesThe number of non-empty source lines. | 10 | +4 |
Intercept 8.87 + feature contributions = -8.456 (log-odds).
Score = sigmoid(-8.456) = 0.
| Score | 0.519 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 11 | +0.647 |
| 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. | 75 | +0.489 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 10 | −0.391 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 9.816 | −0.273 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.076 | +0.202 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 10 | +0.191 |
Intercept 0.07 + feature contributions = 0.13 (log-odds).
Score = sigmoid(0.13) = 0.533.
| Score | 0.452 |
|---|
| Score | 8 |
|---|
Run 1
The code is generally clear and well-structured. It uses a logical sequence: build tag, construct payload, serialize, handle dry-run, and perform the request. Nesting is minimal, and each line performs a coherent action. The conditional expression for the tag is concise. However, readability is slightly reduced by the multi-line function call inside `codecs.encode`, which obscures the structure. Also, `simplejson.dumps(dict(...))` could be more explicit. The dry-run print statement uses old-style formatting and could be clearer. Overall, it is readable but not perfect.
Run 2
The code is moderately readable. Structure is mostly logical, with clear separation between data preparation, request setup, and the dry-run branch. Nesting is flat, which is good. Intent is fairly clear: it builds a release announcement payload and optionally posts it. However, readability is weakened by several issues: the one-line conditional assignment of 'tag' is slightly dense, multiple actions are packed into the 'body' variable assignment (serialization, wrapping, encoding), and line continuation in the dict constructor is awkward. Reading flow is generally natural but interrupted by the long chained expression. Variable naming is mostly good ('release', 'host', 'path'), but 'body' could be more descriptive. Overall, the code is understandable but could benefit from breaking the payload construction into smaller steps and improving the conditional formatting.
Run 3
The code is generally readable with clear intent and a logical flow. It uses flat nesting, concise lines, and each statement largely performs a single action. Minor readability issues include the multi-line function call for `codecs.encode` slightly disrupting flow, the inline conditional for `tag` on the first line, and the lack of descriptive variable names like `body` or `path` beyond their obvious usage. Overall, it is straightforward and maintainable.
Run 1
Code Structure: Logically organized into release preparation, request configuration, and execution. Nesting: Only one shallow if/else, making control flow easy to follow. Clarity of intent: Descriptive names and the dry-run message clearly convey release announcement behavior, though the encoding purpose and tag_list receiving a string are slightly unclear. Code length: Concise without unnecessary repetition. Action granularity: Mostly one action per line; nested serialization and encoding combine related operations but add slight reading effort. Reading flow: Natural progression from metadata to HTTP submission, with minor distractions from uneven continuation indentation and cramped string-formatting spacing.
Run 2
Code Structure: Logically organized into release metadata construction, request preparation, and conditional submission. Nesting: Shallow, with only one straightforward if/else branch. Clarity of intent: Descriptive variable names and the dry-run message make the release-announcement purpose clear, though the encoding choice and tag_list receiving a string are slightly ambiguous. Code length: Concise without unnecessary repetition. Action granularity: Most lines perform one action; nested dictionary construction, JSON serialization, and encoding make the body assignment somewhat dense. Reading flow: Natural progression from preparing data to sending the request, with minor formatting inconsistencies in continuation alignment and string interpolation.
Run 3
Code Structure: Logically organized into release preparation, request setup, and execution. Nesting: Shallow, with only one if/else branch; nested serialization calls add minor complexity. Clarity of intent: Variable names and the dry-run message make the release-announcement purpose clear, though the encoding choice and tag_list accepting a string are less explicit. Code length: Concise without unnecessary statements. Action granularity: Mostly one action per line, although body creation combines dictionary construction, JSON serialization, and encoding. Reading flow: Natural progression from metadata to HTTP submission, slightly hindered by uneven continuation indentation and cramped formatting around the string-formatting operator.