Sample
pyint-56801ce8fec5-I02
Shorten method, parameter, and local names without collisions
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.067 | 0–1; higher is more readable |
| Mi | 0.616 | 0–1; higher is more readable |
| LLOC | 135 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 6.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 12 | 0–20; mean of three runs |
| BTTF | 0.371 | 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. | 9143.007 | −301.719 |
| Source linesThe number of non-empty source lines. | 314 | +125.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. | 4.404 | −6.606 |
Intercept 8.87 + feature contributions = -173.855 (log-odds).
Score = sigmoid(-173.855) = 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. | 315 | −10.117 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 246 | +7.772 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 246 | −5.224 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 313.895 | +3.978 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 93.959 | +0.712 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.047 | +0.482 |
| 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. | 93.94 | −0.314 |
Intercept 0.07 + feature contributions = -2.641 (log-odds).
Score = sigmoid(-2.641) = 0.067.
| Score | 0.616 |
|---|
| Score | 135 |
|---|
Run 1
This code has significant readability issues. The structure is confusing: methods have cryptic names like 'sen', 'get2', 'should', 'rebuild2', 'rebuild3' instead of descriptive names like 'send', 'get_redirect_location', 'should_strip_auth', 'rebuild_proxies', 'rebuild_method'. Variable names are similarly unclear ('res2', 'req3', 'str2', 'tim', 'ver', 'cer', 'pro', 'hea2', 'new3', 'new4'). Multiple abbreviations and inconsistent numbering make the intent difficult to follow. Several lines combine multiple actions or complex expressions, reducing clarity. While the code is logically organized into methods, the poor naming and cryptic parameter names severely hamper readability. Some comments are helpful, but they can't compensate for the naming issues. The reading flow is disrupted by constantly needing to decode abbreviated names.
Run 2
The code has major readability issues. Variable names are meaningless (res2, req3, hea2, url2), making intent difficult to discern. Method names like 'sen', 'get2', 'rebuild', 'rebuild2', 'rebuild3' provide no clue about their purpose. The resolve method is excessively long with multiple nested conditionals and inline comments, violating single-action-per-line principles. While some docstrings exist, they don't compensate for the poor naming. The code structure shows some logical organization with separate methods, but the numbering (rebuild2, rebuild3) suggests disorganized evolution. Deep nesting occurs in conditional blocks. Overall, the code requires significant effort to understand what each part does.
Run 3
The code has severe readability issues. Variable names like 'res2', 'req3', 'str2', 'tim', 'ver', 'cer', 'pro', 'par', 'hea', 'sch', 'new3', 'new4' are cryptic and offer no semantic meaning. Method names such as 'sen', 'get2', 'should', 'rebuild', 'rebuild2', 'rebuild3' are vague and inconsistent. The function 'resolve' is extremely long with deeply nested logic, multiple boolean flags, and a generator that yields different types conditionally. Control flow is hard to follow due to the while loop with early yields and mutations of 'req3' and 'res2'. Comments do not compensate for the poor naming. Overall, the code requires significant mental effort to decipher intent, and appears to be obfuscated or aggressively refactored from a clearer original. It fails nearly all readability criteria: structure is tangled, intent is ambiguous, and the reading flow is disorganized. There are also apparent inconsistencies like '_t' being used without visible import.
Run 1
Code Structure: Responsibilities are logically separated into redirect, authentication, proxy, and method-handling helpers, but resolve combines many operations. Nesting: Mostly shallow conditionals, with moderate nesting inside the redirect loop; no excessive nesting. Clarity of intent: Docstrings, comments, and type annotations explain behavior, but vague names such as get2, rebuild2, req3, hea4, and changed2 substantially obscure meaning. Code length: The extensive redirect handling is largely justified, though long comments, numerous imports unused in this snippet, and the large resolve method increase reading effort. Action granularity: Generally one action per line, with clearly separated mutations and calls. Reading flow: Processing follows a coherent sequence, supported by whitespace and explanatory comments, but cryptic naming forces repeated cross-referencing. References to types not defined or imported in the snippet also distract readers.
Run 2
Code Structure: Related redirect behavior is organized into a mixin and helper methods, but resolve combines many responsibilities. Nesting: Mostly shallow conditionals, with moderate nesting inside the redirect loop. Clarity of intent: Docstrings, comments, and type annotations explain HTTP behavior well, but names such as sen, get2, rebuild2, hea4, and changed2 obscure meaning and force readers to track context. Code length: Most helpers are reasonably concise; resolve is long, and some comments add bulk, although protocol-specific explanations are useful. Action granularity: Statements generally perform one action per line, with clear separation between processing stages. Reading flow: Redirect handling follows a logical sequence, but repeated variable mutation, numbered identifiers, and ambiguous helper calls interrupt comprehension. Overall, sound formatting and informative documentation partially compensate for poor naming and an oversized central method.
Run 3
Code Structure: Separate methods organize redirect, authentication, proxy, and HTTP-method handling logically, but resolve combines many responsibilities. Nesting: Mostly shallow conditionals; the redirect loop adds moderate nesting without becoming excessive. Clarity of intent: Docstrings, explanatory comments, and type annotations help substantially, but abbreviated and numbered names such as sen, rebuild2, req3, and hea4 obscure meaning and distinctions. Code length: Supporting methods are reasonably concise, while resolve is lengthy and could benefit from extracting focused helpers. Action granularity: Most lines perform one action, with no dense chains of statements. Reading flow: Processing generally follows a coherent redirect lifecycle, supported by whitespace and comments, but cryptic naming, repeated mutation, and references to types not defined in the snippet increase the effort needed to follow it.