Sample
pyint-eff5721d7a56-SRC
Unmodified source class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.297 | 0–1; higher is more readable |
| Mi | 0.472 | 0–1; higher is more readable |
| LLOC | 35 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17.67 | 0–20; mean of three runs |
| BTTF | 0.503 | 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. | 2440.842 | −80.548 |
| Source linesThe number of non-empty source lines. | 80 | +32 |
| 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.718 | −7.077 |
Intercept 8.87 + feature contributions = -46.755 (log-odds).
Score = sigmoid(-46.755) = 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. | 81 | −1.832 |
| 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. | 119.975 | −1.416 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 119.988 | +1.131 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 50 | +0.992 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 51 | −0.749 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 79.802 | +0.706 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.072 | +0.238 |
Intercept 0.07 + feature contributions = -0.86 (log-odds).
Score = sigmoid(-0.86) = 0.297.
| Score | 0.472 |
|---|
| Score | 35 |
|---|
Run 1
The code is well-structured and readable. It uses clear class-level documentation, type hints, and a logical method ordering. Nesting is minimal, with only one conditional in __eq__. Intent is clear, especially with the docstring explaining case-insensitive key handling and the lower_items helper. Code length is appropriate—no redundancy. Action granularity is mostly one action per line, though a few generator expressions are slightly dense but still understandable. Reading flow follows the natural progression of a mapping implementation. Minor deductions for the slightly complex generator expressions and the single type: ignore comment, but overall this is highly readable.
Run 2
The code is well-structured with clear separation of methods, strong type hints, and a comprehensive docstring explaining behavior. Nesting is minimal—only one level in `__eq__`. Each method has a single, clear purpose and concise implementation. Readability is enhanced by meaningful variable names and comments that clarify non-obvious logic like the lowercased key storage. The only minor drawbacks are the long `__init__` type annotation line and slight complexity in `__eq__` with type ignore, but overall the code is highly readable.
Run 3
The code is well-structured with clear separation of methods, minimal nesting, and strong readability. Each method performs a single, focused action, and the type hints improve clarity. The docstring is excellent, providing concrete examples of the case-insensitive behavior. The implementation logic is straightforward — using a lowercased key for storage while preserving the original case — and the comments are sparing but helpful. Minor deductions: the `data` variable reassignment in `__init__` is slightly awkward, and `lower_items` could be more concise. Overall, it is clean, idiomatic Python with a natural reading flow and no unnecessary complexity.
Run 1
Code Structure: Logically organized around standard mapping methods, with a consistent internal representation. Nesting: Very shallow; only simple conditional branches appear. Clarity of intent: The class docstring, type annotations, and storage comment clearly explain case-insensitive behavior, although the undefined _VT type variable and unused imports distract and leave the snippet incomplete. Code length: Methods are concise; the extensive docstring is useful but somewhat repetitive. Action granularity: Almost every line performs one clear action, with generator expressions remaining reasonably readable. Reading flow: Methods follow a natural progression from initialization through basic operations, comparison, copying, and representation. Minor weaknesses include the lengthy inline type-ignore comment, tuple indexing in lower_items, and the vague 'Copy is required' comment.
Run 2
Code Structure: Methods are logically organized around the mapping interface, with a consistent internal representation. Nesting: Control flow is shallow, with only simple conditionals. Clarity of intent: The class docstring, type annotations, and storage comment clearly explain case-insensitive lookup and preserved key casing. However, _VT is never defined despite importing TypeVar, and names such as keyval are less descriptive. Code length: Methods are concise; the extensive docstring is useful, though somewhat repetitive. Action granularity: Statements generally perform one action per line; generator expressions remain compact and understandable. Reading flow: Construction, core mapping operations, comparison, copying, and representation follow a natural sequence. The long type-ignore line and tuple indexing slightly interrupt readability.
Run 3
Code Structure: Logically organized into short, focused mapping methods with a consistent internal representation. Nesting: Very shallow, with only simple conditionals and generator expressions. Clarity of intent: The class docstring, type annotations, and storage comment clearly explain case-insensitive lookup and preserved key casing. However, _VT is never defined in the snippet despite importing TypeVar, and names such as keyval are less descriptive. Code length: Implementation is concise; the lengthy docstring provides useful context, though some references to legacy iteration methods add clutter. Action granularity: Statements generally perform one action per line; tuple indexing and comprehensions remain manageable. Reading flow: Methods follow a natural progression from initialization through core mapping operations to comparison, copying, and representation. The long inline type-ignore comment slightly interrupts the otherwise clean presentation.