Sample
pyint-554d82fc50e3-I06
Invert eligible conditions and exchange their branches
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.198 | 0–1; higher is more readable |
| Mi | 0.561 | 0–1; higher is more readable |
| LLOC | 100 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 10 | 0–20; mean of three runs |
| GPT-6.1 Sol | 12.67 | 0–20; mean of three runs |
| BTTF | 0.276 | 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. | 6877.14 | −226.946 |
| Source linesThe number of non-empty source lines. | 222 | +88.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.239 | −6.358 |
Intercept 8.87 + feature contributions = -135.634 (log-odds).
Score = sigmoid(-135.634) = 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. | 223 | −6.859 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 205 | +6.354 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 205 | −4.283 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 221.938 | +2.692 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 95.556 | +0.737 |
| 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. | 95.942 | −0.398 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.067 | +0.291 |
Intercept 0.07 + feature contributions = -1.397 (log-odds).
Score = sigmoid(-1.397) = 0.198.
| Score | 0.561 |
|---|
| Score | 100 |
|---|
Run 1
The code has clear type hints and docstrings but suffers from several readability issues. The imports are organized but lengthy, taking up nearly half the file. The path_url property uses inverted conditionals (if not (not path)) that obscure intent, making simple logic needlessly complex. The _encode_params method has extremely long lines and nested comprehensions that reduce clarity. _encode_files contains deep nesting with multiple conditional branches and counterintuitive empty pass blocks alongside else clauses. Variable names like p, v, fp, ft, fh are cryptic without context. The action granularity is inconsistent - some lines pack multiple operations while others spread simple logic across many lines. Reading flow is disrupted by the unnatural conditional structures and heavy type annotation clutter. Structure improvements, clearer conditionals, and better naming would significantly improve readability.
Run 2
The code shows mixed readability. Imports are well-organized and type hints are extensive, which aids clarity. However, several areas significantly hurt readability: The path_url property uses awkward double-negative conditions like `if not (not path): pass else:`, which obscures intent. Similar inverted logic appears throughout _encode_files and _encode_params with empty pass branches that force readers to mentally reverse conditions. The _encode_params method has deep nesting and complex type handling that could be broken into smaller helpers. Some methods are long and try to do too much, particularly _encode_files. While the docstrings are helpful and variable names are mostly descriptive, the inverted conditionals and pass-else patterns create confusing reading flow. Action granularity is generally good, but the control flow structure makes the code unnecessarily difficult to follow.
Run 3
The code demonstrates poor readability due to several factors. The most glaring issue is the inverted conditional logic in multiple places (e.g., `if not (not path): pass else: path = "/"` and `if not (isinstance(v, basestring)...): pass else: val = [val]`), which creates unnecessary nesting depth and cognitive load. These patterns should use simple positive conditions. The `path_url` property has odd empty blocks and multiple actions that could be simplified. Function signatures are heavily overloaded, which adds complexity but is somewhat justified for type safety. Import statements are extensive but organized logically. The `_encode_files` method is particularly long with deeply nested conditionals and variable assignments that obscure the data flow. Variable names like `ft`, `fh`, `fp`, `fn` are cryptic. The code has good docstrings but the actual implementation contradicts the clarity they provide. Type hints are used extensively but sometimes add visual noise. Overall structure follows a logical organization, but the internal logic flow and conditional patterns significantly hamper readability.
Run 1
Code Structure: Organized into a focused mixin with separate URL, parameter, and multipart encoding methods, although the extensive imports distract from the implementation. Nesting: Moderate to deep nesting in encoding loops and conditional branches makes multipart handling harder to follow. Clarity of intent: Descriptive method names, docstrings, and type annotations clarify purpose, but inverted conditions, double negatives, empty pass branches, and abbreviated variables obscure details. Code length: Overloads provide useful typing, but redundant if/pass/else patterns unnecessarily lengthen otherwise straightforward logic. Action granularity: Most lines perform a single action, with tuple construction and inline conditional conversions adding some density. Reading flow: Method organization and spacing are consistent, but unnatural condition phrasing and nested alternatives interrupt the flow and require extra mental effort.
Run 2
Code Structure: Imports, a focused mixin, and separate encoding methods provide logical organization. Nesting: Parameter and file processing involve several nested loops and conditionals, increasing cognitive load. Clarity of intent: Method names, docstrings, and type annotations explain the purpose well, but inverted conditions, double negatives, and empty pass branches obscure straightforward decisions; abbreviated variables also reduce clarity. Code length: Most implementation detail is justified, though redundant conditional branches and extensive typing declarations make the snippet longer to scan. Action granularity: Statements generally perform one action per line, with clearly formatted tuple construction and function calls. Reading flow: Methods follow a sensible input-validation-to-processing-to-return sequence, but repeated 'if not ...: pass; else: ...' patterns interrupt natural reading. Overall, the code is understandable and organized, but unnecessarily convoluted conditionals prevent a higher score.
Run 3
Code Structure: Imports, a focused mixin, and separate encoding methods provide logical organization. Nesting: Parameter and file encoding contain several nested loops and conditionals, making some paths harder to follow. Clarity of intent: Method names, docstrings, and type annotations explain the purpose, but inverted conditions, double negatives, empty pass branches, and abbreviated variables obscure otherwise simple logic. Code length: The implementation is moderately concise, although redundant branches and extensive typing declarations increase reading overhead. Action granularity: Most lines perform one action; tuple unpacking and conditional expressions remain reasonably understandable. Reading flow: Methods follow a sensible progression from validation to transformation and return, but unnecessary else branches and negated tests repeatedly interrupt that flow. Overall, the code is understandable but would benefit substantially from direct conditions, guard clauses, and clearer local names.