Sample
pyint-39e3130169a1-I08
Select one of ten high-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.018 | 0–1; higher is more readable |
| Mi | 0.598 | 0–1; higher is more readable |
| LLOC | 149 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs |
| BTTF | 0.548 | 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. | 8991.076 | −296.705 |
| Source linesThe number of non-empty source lines. | 302 | +120.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.386 | −6.578 |
Intercept 8.87 + feature contributions = -173.614 (log-odds).
Score = sigmoid(-173.614) = 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. | 303 | −9.692 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 202 | +6.25 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 202 | −4.214 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 301.807 | +3.809 |
| 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.993 | −2.01 |
| 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.442 |
Intercept 0.07 + feature contributions = -3.989 (log-odds).
Score = sigmoid(-3.989) = 0.018.
| Score | 0.598 |
|---|
| Score | 149 |
|---|
Run 1
The code is well-structured with clear separation of concerns. Each method has a single responsibility and includes helpful docstrings explaining purpose and complexity (e.g., O(n) warnings). The class organization is logical, grouping related dictionary-interface methods together. Nesting is generally acceptable; the deepest indentation occurs in _find_no_duplicates with four levels, which is manageable. There is an unused variable 'even_number_count' in __getstate__ that appears to be dead code, slightly reducing clarity. Type hints are used consistently, aiding readability. However, some minor issues: the '__getstate__' method contains unnecessary loops unrelated to pickling, and a few type-ignore comments suggest possible mismatches. Overall, the code is clear, well-documented, and easy to follow despite some minor clutter.
Run 2
The code is well-structured and highly readable, organized around a single class with logically grouped methods. It maintains mostly flat nesting, though `_find` and `_find_no_duplicates` have three and four levels respectively, which slightly reduces readability. Intent is clear through detailed docstrings and method names. Length is reasonable — methods are concise and do not over-abstract. Action granularity is good, with one action per line in most cases. Reading flow is natural, as methods follow a logical progression and adhere to common mapping/cookie-jar patterns. Minor deductions stem from deep nesting in `_find_no_duplicates`, slight redundancy in helper loops (e.g., `list_domains`, `list_paths`, `multiple_domains` could share a set-building helper), and an apparently meaningless loop variable in `__getstate__` (`even_number_count`) that detracts from clarity. Overall, it is clean, maintainable, and easily understood code.
Run 3
The code is generally readable with clear class-level docstrings, consistent method-level documentation, and logical grouping of dict-interface methods followed by internal helpers. Naming is explicit (e.g., `_find_no_duplicates`) and methods are short and focused. However, readability is weakened by unnecessary nested conditionals in `_find` and `_find_no_duplicates`, verbose repetitive iteration patterns in `list_domains`, `list_paths`, and `multiple_domains`, and some odd leftover code (e.g., the `__getstate__` even_number_count loop). Type hints are extensive but sometimes add visual clutter. The action granularity is mostly one action per line, but a few complex conditions and the `set_cookie` walrus expression reduce scanability. Overall, the structure and intent are clear, but minor cleanup would improve readability.
Run 1
1. Code Structure: Methods are logically separated into mapping operations, lookup helpers, serialization, and copying, though imports are inconsistently grouped. 2. Nesting: Most methods are shallow, but lookup helpers contain several nested conditionals that could be flattened. 3. Clarity of intent: Descriptive method names, annotations, and extensive docstrings explain the interface well. However, misleading documentation in multiple_domains and __setitem__, the vague toReturn variable, and unrelated counting logic in __getstate__ undermine clarity. 4. Code length: Individual methods are generally concise, but repetitive documentation and duplicated filtering logic increase overall length unnecessarily. 5. Action granularity: Almost every statement performs one action; the assignment expression in set_cookie slightly increases reading effort. 6. Reading flow: Related methods are grouped naturally and delegation is easy to follow, but long type-ignore comments, deeply nested searches, and dead counting code interrupt the flow.
Run 2
Code Structure: Methods are logically grouped around a cookie jar's mapping interface, lookup, and serialization, but unrelated counting logic in __getstate__ disrupts cohesion. Nesting: Most methods are shallow, although _find and _find_no_duplicates contain unnecessarily deep conditional chains. Clarity of intent: Descriptive method names, annotations, and extensive docstrings generally clarify purpose; however, multiple_domains checks for repeated domains rather than distinct domains, some documentation mismatches behavior, and toReturn is an inconsistent, vague name. Code length: Small methods are concise, but repetitive documentation, duplicated lookup logic, and unused counting code add bulk. Action granularity: Statements generally perform one action per line; the assignment expression in set_cookie slightly increases cognitive load. Reading flow: Consistent formatting and straightforward delegation support natural reading, while inconsistent import ordering, long suppression comments, and deeply nested searches interrupt it.
Run 3
Code Structure: Methods are logically separated into mapping operations, cookie lookup, serialization, and copying, though imports are inconsistently grouped. Nesting: Most methods are shallow, but lookup helpers contain several nested conditions that could be flattened. Clarity of intent: Descriptive method names, annotations, and extensive docstrings explain the interface well. However, multiple_domains checks repeated domains rather than distinct domains, some documentation contradicts implementation, and toReturn is an inconsistent, vague name. Code length: Much of the length supports documentation and compatibility, but repetitive lookup logic and the unused even-number counting loop in __getstate__ add unnecessary bulk. Action granularity: Statements generally perform one action per line; the assignment expression in set_cookie adds only minor complexity. Reading flow: Small methods and consistent formatting make navigation straightforward, although long type-ignore comments, repetitive documentation, and unexplained dead code interrupt the flow.