Sample
pyint-8ae23f15abf4-SRC
Unmodified source class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.64 | 0–1; higher is more readable |
| Mi | 0.598 | 0–1; higher is more readable |
| LLOC | 145 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 15.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.572 | 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. | 8743.824 | −288.546 |
| Source linesThe number of non-empty source lines. | 298 | +119.2 |
| 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.384 | −6.576 |
Intercept 8.87 + feature contributions = -167.052 (log-odds).
Score = sigmoid(-167.052) = 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. | 299 | −9.55 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 198 | +6.111 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 297.822 | +3.753 |
| 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.973 | −2.009 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 133.99 | +1.357 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.051 | +0.443 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = 0.573 (log-odds).
Score = sigmoid(0.573) = 0.64.
| Score | 0.598 |
|---|
| Score | 145 |
|---|
Run 1
The code is generally readable with clear class structure, good docstrings, and methods organized logically. It has a flat nesting hierarchy with no deeply nested code blocks. Most methods perform one action per line and have clear intent. However, it loses points for excessive boilerplate - many methods like iterkeys/keys, itervalues/values, iteritems/items have redundant documentation and repetitive implementation patterns. The type annotations are helpful but add visual noise. The walrus operator in set_cookie slightly reduces readability. Some methods like _find and _find_no_duplicates use 3-4 levels of nesting, though still manageable. Overall, the code is well-organized and maintainable, but verbosity in documentation and repetitive patterns prevent a higher score.
Run 2
This code is highly readable. The structure is logical, organizing a complex compatibility class into clear, focused methods. Each method has a single responsibility and is documented with concise docstrings that explain both purpose and any performance caveats (e.g., O(n) warnings). Nesting is mostly shallow; even the deeper loops in _find and _find_no_duplicates are understandable. Naming is clear, and type hints improve clarity. The reading flow is natural, with methods grouped by functionality (dict interface, iteration, lookup, utilities). Action granularity is good: one action per line for the most part, and helper functions/classes are well-encapsulated. One minor readability issue is the inconsistent use of camelCase in `toReturn`, but it does not meaningfully detract from the overall clarity. Import organization is slightly redundant (e.g., importing CookieJar and cookielib), but not confusing. Overall, the code balances conciseness with explanatory documentation and generous whitespace, making it easy to follow and maintain.
Run 3
The code is generally well-structured and readable, with clear method names and docstrings explaining intent. However, readability is hindered by type comments, frequent method overrides with type-ignore, and some inconsistent variable naming (e.g., 'toReturn' instead of 'to_return'). The nesting in `_find` and `_find_no_duplicates` reaches three levels, slightly reducing flow. While the class is logically organized, its dual role as CookieJar and MutableMapping creates some cognitive overhead. Overall, the code is understandable but not perfectly polished.
Run 1
Code Structure: Methods are logically separated into mapping operations, cookie lookup, serialization, and copying, though explicit grouping could improve navigation. Nesting: Most methods are shallow, but _find and _find_no_duplicates contain unnecessarily deep conditional chains. Clarity of intent: Descriptive method names, type annotations, and extensive docstrings clarify purpose; however, toReturn is vague, and multiple_domains checks repeated domains rather than distinct domains, contradicting its stated intent. Code length: Individual methods are generally concise, but repetitive iterator wrappers and verbose documentation make the class lengthy. Action granularity: Statements predominantly perform one action per line; the assignment expression in set_cookie slightly increases reading effort. Reading flow: Consistent formatting and predictable method patterns support natural reading, while inconsistent import placement, long inline type-ignore comments, and duplicated lookup logic create minor distractions.
Run 2
Code Structure: Methods are logically grouped around dictionary compatibility, cookie lookup, and serialization, with clear separation of responsibilities. Nesting: Most methods are shallow, but _find and _find_no_duplicates contain unnecessarily deep conditional chains. Clarity of intent: Descriptive method names, type annotations, and extensive docstrings help, although toReturn is vague and inconsistently styled. Some documentation contradicts implementation: multiple_domains detects repeated domains rather than distinct ones, and __setitem__ does not explicitly reject existing names. Code length: Mostly concise methods, but repetitive wrappers, lookup logic, and verbose docstrings increase reading overhead. Action granularity: Statements generally perform one action each; the assignment expression in set_cookie slightly increases cognitive load. Reading flow: Consistent formatting and short methods make navigation natural, though import ordering, long suppression comments, and nested matching conditions interrupt the flow.
Run 3
Code Structure: Logically organized into focused methods for mapping operations, cookie lookup, and serialization, although imports are inconsistently grouped. Nesting: Most methods are shallow, but the lookup helpers contain several nested conditions that could be flattened. Clarity of intent: Descriptive method names, type annotations, and extensive docstrings explain the API well; however, multiple_domains checks for repeated domains rather than distinct domains, and some docstrings do not match implementation behavior. Code length: Individual methods are generally concise, but repetitive documentation and duplicated filtering logic make the class lengthy. Action granularity: Statements generally perform one action per line; the assignment expression in set_cookie slightly increases cognitive load. Reading flow: Consistent formatting and related method grouping support natural reading, though long type-ignore comments, the nonstandard toReturn name, and deeply nested lookup logic interrupt it.