Sample
pyint-c4bef8dfb4ff-I02
Shorten method, parameter, and local names without collisions
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.006 | 0–1; higher is more readable |
| Mi | 0.561 | 0–1; higher is more readable |
| LLOC | 192 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 7.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 11.33 | 0–20; mean of three runs |
| BTTF | 0.352 | 0–1; higher is more readable |
Views
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. | 13194.193 | −435.408 |
| Source linesThe number of non-empty source lines. | 422 | +168.8 |
| 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.475 | −6.713 |
Intercept 8.87 + feature contributions = -264.451 (log-odds).
Score = sigmoid(-264.451) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 423 | −13.941 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 333 | +10.781 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 333 | −7.22 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 421.978 | +5.489 |
| 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. | 133.965 | −2.009 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 133.983 | +1.357 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.052 | +0.439 |
Intercept 0.07 + feature contributions = -5.034 (log-odds).
Score = sigmoid(-5.034) = 0.006.
| Score | 0.561 |
|---|
| Score | 192 |
|---|
Run 1
The code suffers from severely obfuscated naming (prepare2, prepare6, met, url3, hea2, etc.), making the flow difficult to follow. While the overall class structure is logical and docstrings clarify some intent, the abbreviated identifiers destroy readability. The original requests library uses descriptive names like prepare_url and prepare_headers; these replacements are cryptic. Nesting is mostly manageable, and line lengths are reasonable, but the 'action granularity' suffers in places where parsing and assignment are densely packed. The reading flow is unnatural: a reader must constantly map numbered methods and short variables back to their true purpose. The type annotations are modern and helpful, but cannot compensate for the naming. Overall, this is readable only with significant mental translation effort, scoring low on clarity of intent and natural flow.
Run 2
The code suffers from severe readability issues. Method names like 'pre', 'prepare2', 'prepare3', 'prepare7' convey no meaning, making the call flow in 'pre' completely opaque. Variable names are cryptic ('met', 'url2', 'hea', 'fil', 'dat', 'par', 'aut', 'coo', 'hoo', 'jso', 'hos2', 'pat', 'que', 'fra'), forcing readers to constantly track what each abbreviation represents. The 'pre' method calls preparation steps in a scattered order (1, 2, 3, 7, 4, 6, 8), which destroys logical flow. While the code is relatively flat and one action per line is mostly respected, the original intent of each method is obscured by renaming ('prepare2' was likely 'prepare_url', etc.). Comments exist but cannot compensate for poor naming. The overall structure follows a logical domain pattern, but the systematic stripping of meaningful identifiers makes this code nearly unreadable. Only the docstrings and some inline comments provide any clarity.
Run 3
The code exhibits severe readability issues due to deliberately obfuscated naming (prepare2, prepare3, prepare7, get2, url3, aut2, etc.) that obscures intent and breaks reading flow. Nested logic and dense methods, especially prepare4, create deep branching and high cognitive load. Multiple actions are often packed into single lines with type ignores and casts, reducing clarity. The class docstring and comments provide some context, but they cannot compensate for the cryptic identifier names and fragmented method sequencing (prepare6 before prepare7, prepare8 after prepare7). Overall, the code is difficult to follow and would require significant renaming and restructuring to be maintainable.
Run 1
Code Structure: Responsibilities are separated into methods, and request preparation follows a logical sequence. Nesting: Mostly moderate, but body preparation contains several nested branches and exception handlers. Clarity of intent: Docstrings, comments, and type annotations help, but numbered method names such as prepare2 and abbreviated variables such as dat2 and hos2 obscure meaning. Comments referencing original method names further complicate navigation. Code length: Generally justified by protocol handling, though lengthy comments, numerous imports, and a large body-preparation method increase reading effort. Action granularity: Statements generally perform one action per line, with few dense expressions. Reading flow: Formatting and sequential processing are consistent, but readers must repeatedly map opaque identifiers to their roles; numbered calls also conceal dependencies between preparation stages.
Run 2
Code Structure: Request preparation is logically separated into methods, but numbered method names obscure their responsibilities. Nesting: Most methods are fairly flat; body preparation has several nested branches and exception handlers that increase cognitive load. Clarity of intent: Docstrings, type annotations, and explanatory comments help, but abbreviated variables such as dat2, hos2, and aut3 substantially weaken clarity. Comments referencing original method names also conflict with the actual names. Code length: Much of the length reflects legitimate HTTP handling, though extensive imports, verbose annotations, and some redundant or irrelevant comments add noise. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Preparation follows a sensible sequence, but calls such as prepare7 followed by prepare4 require consulting definitions to understand the pipeline. Overall, solid organization and formatting are undermined by opaque naming and a complex body-preparation routine.
Run 3
Code Structure: Request preparation is logically split into methods, but numbered method names obscure responsibilities and dependencies. Nesting: Most methods are fairly flat, while body preparation contains several nested branches and exception handlers that increase cognitive load. Clarity of intent: Docstrings, type annotations, and explanatory comments help, but abbreviated variables such as dat2, hos2, and aut3 substantially hinder understanding; comments also reference method names absent from the snippet. Code length: Much of the length reflects legitimate HTTP handling, though extensive imports, repetitive comments, and a long body-preparation method reduce concision. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: The preparation sequence provides a coherent overall workflow, but calls such as prepare7 followed by prepare4 and prepare6 require repeatedly consulting definitions. Overall, the organization and formatting are solid, but weak naming significantly undermines readability.