Sample
pyint-cf6940ad79f0-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.121 | 0–1; higher is more readable |
| Mi | 0.545 | 0–1; higher is more readable |
| LLOC | 159 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 8 | 0–20; mean of three runs |
| GPT-6.1 Sol | 14 | 0–20; mean of three runs |
| BTTF | 0.314 | 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. | 10189.129 | −336.241 |
| Source linesThe number of non-empty source lines. | 270 | +108 |
| 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.459 | −6.688 |
Intercept 8.87 + feature contributions = -226.059 (log-odds).
Score = sigmoid(-226.059) = 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. | 271 | −8.559 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 223 | +6.976 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 224 | −4.719 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 269.886 | +3.363 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 86.292 | +0.588 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.065 | +0.313 |
| 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. | 86.948 | −0.018 |
Intercept 0.07 + feature contributions = -1.986 (log-odds).
Score = sigmoid(-1.986) = 0.121.
| Score | 0.545 |
|---|
| Score | 159 |
|---|
Run 1
This code has significant readability issues. The most glaring problem is the repeated dead-code assertions `if ((0x918 ^ 0x918) != 0): raise AssertionError()` before nearly every method and property, which adds noise and obscures intent. These checks always evaluate to false and provide no value, making the code unnecessarily long and cluttered. The class structure is logical, and methods are generally short with one action per line, but the excessive assertions break the reading flow. Additionally, the use of low-level ctypes pointers and C API calls (capi, geom_api, srs_api) makes the code hard to follow without deep familiarity with GDAL internals. While docstrings are helpful, the overall clarity suffers from defensive programming artifacts and verbose error-checking that could be simplified or removed. The nesting is acceptable, but the code length is inflated by repetitive boilerplate, and the intent is buried under layers of low-level details and guard clauses.
Run 2
The code is severely degraded by pervasive obfuscation: every method contains a useless assertion check like 'if ((0x918 ^ 0x918) != 0): raise AssertionError()' which evaluates to false and adds noise. This destroys reading flow, inflates code length, and obscures intent. While the underlying class structure is logical and docstrings are clear, the nested list comprehensions in properties like fields, field_types, and field_widths reduce action granularity and readability. The _set_spatial_filter method has reasonable structure but is also buried under the same obfuscation pattern. Overall, the code is functionally organized but practically unreadable due to deliberate clutter.
Run 3
The code is well-structured and highly readable overall. It follows a logical organization: initialization, dunder methods, helper methods, properties, and public methods are clearly grouped. Nesting is minimal, with only a few reasonably flat conditional blocks. Intent is generally clear through descriptive method/property names and concise docstrings. Code length is appropriate, though some repetition exists in property accessors for field metadata. Action granularity is good—most lines perform one operation, though list comprehensions pack multiple actions. The main issue affecting readability is the presence of many meaningless `if ((0x... ^ 0x...) != 0): raise AssertionError()` lines, which are likely obfuscation artifacts and interrupt the natural reading flow. Without these, the code would be notably cleaner. Overall, the code demonstrates strong Django/GIS library conventions, clear error handling, and good separation of concerns.
Run 1
1. Code Structure: Logically organized into initialization, iteration/indexing, properties, and methods, with focused helpers. 2. Nesting: Generally shallow; feature lookup and spatial-filter validation introduce manageable nesting. 3. Clarity of intent: Descriptive names, docstrings, and comments explain the wrapper well, but repeated always-false hexadecimal XOR assertions obscure intent and suggest nonexistent validation. Nested C API calls also require domain knowledge. 4. Code length: Most methods are concise, but redundant assertions throughout unnecessarily inflate the class. Some comments repeat obvious behavior. 5. Action granularity: Statements generally perform one action per line; comprehensions and nested calls combine related operations reasonably. 6. Reading flow: Consistent formatting and logical grouping support navigation, but meaningless assertion blocks repeatedly interrupt the actual logic. Overall, the underlying design is readable, with substantial avoidable noise.
Run 2
Code Structure: The class is logically organized into initialization, special methods, properties, and layer operations, with focused responsibilities. Nesting: Generally shallow; feature lookup and spatial-filter validation introduce only moderate nesting. Clarity of intent: Descriptive names, docstrings, and comments explain the GIS wrapper well, but repeated always-false hexadecimal XOR checks suggest unexplained behavior and distract from actual functionality. Code length: Most methods are concise, yet redundant assertion blocks substantially inflate the class. Action granularity: Statements generally perform one action per line; nested API calls and comprehensions occasionally require extra parsing. Reading flow: Consistent formatting and clear section boundaries support natural reading, but the meaningless checks interrupt nearly every method. Low-level API aliases and inconsistent use of ptr versus _ptr also slightly increase cognitive load.
Run 3
Code Structure: Well organized into a cohesive class, special methods, properties, and layer operations. Nesting: Generally shallow; feature lookup and spatial-filter validation have modest, understandable nesting. Clarity of intent: Descriptive names, docstrings, and useful comments explain most behavior, but repeated always-false hexadecimal XOR checks suggest nonexistent validation and distract from the purpose. Code length: Most methods are concise, but the redundant assertion blocks substantially inflate the class. Action granularity: Statements generally perform one action per line; nested API calls and comprehensions occasionally require extra parsing. Reading flow: Consistent formatting and logical grouping support natural reading, but the meaningless checks interrupt nearly every method. Overall, the underlying implementation is readable, with a significant penalty for pervasive distracting dead code.