Sample
pyint-c71433ce8d92-I09
Select one of ten low-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.294 | 0–1; higher is more readable |
| Mi | 0.472 | 0–1; higher is more readable |
| LLOC | 39 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 14.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.331 | 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. | 2596.506 | −85.685 |
| Source linesThe number of non-empty source lines. | 85 | +34 |
| 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.747 | −7.121 |
Intercept 8.87 + feature contributions = -49.935 (log-odds).
Score = sigmoid(-49.935) = 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. | 86 | −2.009 |
| 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.988 | −1.417 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 56 | +1.2 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 119.965 | +1.131 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 56 | −0.864 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 84.744 | +0.775 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.072 | +0.239 |
Intercept 0.07 + feature contributions = -0.875 (log-odds).
Score = sigmoid(-0.875) = 0.294.
| Score | 0.472 |
|---|
| Score | 39 |
|---|
Run 1
The code is generally well-structured and readable, with clear class and method documentation. However, there are a few issues that prevent a higher score. The use of obfuscated variable names and meaningless bitwise operations in __getitem__ (e.g., lI0O_ef028acd) significantly harms clarity and appears accidental or malicious. The logic in __eq__ is decent but returns NotImplemented inside an else branch, which is correct but somewhat indirect. The use of type hints and generics is good, and the class structure is logical. Most methods are flat and concise, with good action granularity. The reading flow is mostly natural but interrupted by the obfuscated block. Overall, it is readable but has a notable exception that should be cleaned up.
Run 2
The code is generally well-structured, with clear class organization, type hints, and docstrings that explain the intended behavior. The methods are concise and mostly follow a flat structure with minimal nesting. However, readability is hurt by several factors. The obfuscated variable and bitwise operations in __getitem__ (e.g., lI0O_ef028acd) serve no functional purpose and significantly obscure intent. Additionally, there is an undefined type variable _VT in the class declaration, creating ambiguity. The __eq__ method contains a local type annotation that may confuse readers. Some generator expressions reduce vertical length but slightly compress comprehension. Overall, the code is accessible to an experienced Python developer, but the deliberate obfuscation and missing type variable declaration lower its clarity.
Run 3
The code is generally readable but has notable issues. The class structure is logical with clear docstrings and type hints, but some sections are less maintainable. Variable names like 'lI0O_ef028acd' and the unnecessary branch logic in __getitem__ are confusing and likely the result of obfuscation or poor formatting. The nesting is flat, which is good, and action granularity is mostly one action per line. However, the lower_items method is slightly long and could be more explicit. The use of generics and OrderedDict is clear, but the type error suppression comments and the handling of __eq__ add complexity. Overall, the code would benefit from cleaner naming and removing dead code, but the structure and intent are mostly understandable.
Run 1
Code Structure: Well-organized mapping class with small, logically separated methods. Nesting: Mostly flat, with only shallow conditional branches. Clarity of intent: Descriptive method names, type annotations, and a detailed docstring explain case-insensitive behavior, but the obfuscated variable and pointless bitwise operations in __getitem__ distract from its purpose; _VT is also undefined in the shown code. Code length: Generally concise, though __getitem__ contains unnecessary lines and the docstring is somewhat verbose. Action granularity: Statements generally perform one action per line; generator expressions remain compact and understandable. Reading flow: Standard mapping methods appear in a natural order, but the irrelevant conditional interrupts an otherwise straightforward implementation.
Run 2
Code Structure: Well-organized class with short methods implementing a consistent mapping interface. Nesting: Shallow throughout, though __getitem__ contains a pointless conditional. Clarity of intent: The detailed docstring, type annotations, and descriptive method names explain case-insensitive behavior clearly; however, the obfuscated variable and no-op bitwise operations distract, and _VT is not defined in the provided code. Code length: Mostly concise, with unnecessary statements in __getitem__ and some unused imports. Action granularity: Generally one action per line, making operations easy to follow. Reading flow: Methods appear in a natural order, from initialization through mapping operations to comparison and representation, but the injected dead code interrupts an otherwise straightforward implementation.
Run 3
Code Structure: Well-organized class with small, focused methods implementing a familiar mapping interface. Nesting: Mostly flat, with only shallow conditional branches. Clarity of intent: The detailed docstring, descriptive method names, and type annotations explain case-insensitive storage clearly, but the cryptic variable and meaningless bitwise operations in __getitem__ distract from its purpose. The missing _VT definition also makes the generic declaration harder to understand. Code length: Most methods are concise; the redundant __getitem__ logic and lengthy documentation add some unnecessary reading. Action granularity: Statements generally perform one action per line, while generator expressions remain reasonably understandable. Reading flow: Methods follow a natural progression from initialization through mapping operations to comparison and representation, but the injected no-op branch interrupts an otherwise clean flow.