Sample
pyint-5dd03a65ae50-I06
Invert eligible conditions and exchange their branches
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.189 | 0–1; higher is more readable |
| Mi | 0.526 | 0–1; higher is more readable |
| LLOC | 119 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 14.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.351 | 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. | 7719.666 | −254.749 |
| Source linesThe number of non-empty source lines. | 232 | +92.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.393 | −6.59 |
Intercept 8.87 + feature contributions = -159.669 (log-odds).
Score = sigmoid(-159.669) = 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. | 233 | −7.213 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 185 | +5.662 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 185 | −3.824 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 231.909 | +2.832 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 86.901 | +0.598 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.052 | +0.438 |
| 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.957 | −0.018 |
Intercept 0.07 + feature contributions = -1.457 (log-odds).
Score = sigmoid(-1.457) = 0.189.
| Score | 0.526 |
|---|
| Score | 119 |
|---|
Run 1
The code is generally well-organized with clear class structure, docstrings, and logical grouping of properties and methods. However, several readability issues exist: (1) Double-negative conditionals like `if not (not layer_ptr): pass else: raise` are convoluted and should be simplified to `if not layer_ptr: raise`. (2) Inverted validation patterns `if not (field_name not in self.fields): pass else: raise` are confusing and should use positive logic. (3) Some methods have unnecessary nesting or indirect flow (e.g., `_make_feature` uses if-else where a guard clause would be clearer). (4) While list comprehensions are concise, they sometimes sacrifice clarity (e.g., `field_types` and nested `capi` calls on one line). (5) The `get_geoms` method could be flattened. Overall, the code is maintainable but would benefit from cleaner conditionals, flatter structure, and reduced double negatives.
Run 2
The code is generally well-structured with clear class organization and docstrings explaining purpose. However, several readability issues persist. The constructor contains an awkward inverted conditional ('if not (not layer_ptr): pass else: raise') that should simply be 'if not layer_ptr: raise'. Similar unnecessary double-negative patterns appear in _make_feature and get_fields. The __getitem__ method has reasonable structure but could be cleaner. Action granularity is mostly good with one operation per line, and nesting is generally shallow. Property methods are concise and clear. The list comprehensions in fields, field_types, etc., are efficient but slightly dense due to nested ctypes calls. Reading flow is natural with logical grouping of properties and methods. Overall, the code is maintainable but would benefit from removing counterintuitive conditional patterns and simplifying some of the more dense expressions.
Run 3
The code is generally well-structured and readable, with clear class organization, descriptive method names, and helpful docstrings. However, there are several instances of awkward inverted conditional patterns (e.g., `if not (not layer_ptr): pass else: raise`) that reduce clarity and should be simplified for better readability. Nesting is mostly flat, and intent is clear throughout. Code length is appropriate for the functionality, though some methods could be more concise. Action granularity is good—one action per line in most cases—and reading flow is natural. The main deductions come from the convoluted conditionals and minor verbosity in some property definitions.
Run 1
1. Code Structure: Well organized into initialization, Python protocol methods, properties, and layer operations; responsibilities are mostly separated. 2. Nesting: Generally shallow, with modest nesting in feature lookup and spatial-filter validation. 3. Clarity of intent: Descriptive names, docstrings, and comments explain the GDAL wrapper, but double negatives such as 'if not (not layer_ptr)' and empty pass branches obscure simple validation. 4. Code length: Most methods are concise; some comments, repetitive property implementations, and unnecessary else branches add verbosity. 5. Action granularity: Statements generally perform one action per line, although nested C API calls in comprehensions require extra parsing. 6. Reading flow: Consistent formatting and section headings support natural navigation. Awkward negated conditions, inconsistent use of ptr versus _ptr, and the spatial_filter property being declared separately from other properties slightly disrupt the flow.
Run 2
Code Structure: Well organized into initialization, collection operations, properties, filters, and methods, with focused responsibilities. Nesting: Generally shallow, though feature lookup and filter validation introduce modest nesting. Clarity of intent: Descriptive names, docstrings, and comments explain the GIS wrapper well; double negatives, redundant parentheses, and empty pass branches obscure straightforward conditions. Code length: Mostly concise methods and comprehensions, but repetitive property implementations and some verbose documentation add bulk. Action granularity: Most statements perform one action; nested API calls in comprehensions require additional parsing. Reading flow: Logical grouping and consistent formatting make navigation easy, while inverted conditions, inconsistent ptr/_ptr usage, and mixed property declaration styles slightly disrupt the flow.
Run 3
Code Structure: The class is logically organized into initialization, iteration, properties, filtering, and utility methods. Nesting: Mostly shallow, with moderate nesting in feature lookup and filter validation. Clarity of intent: Descriptive method names, docstrings, and comments explain the wrapper well, but double negatives, redundant parentheses, and empty pass branches obscure simple checks. Code length: Methods are generally concise; some verbose documentation and unnecessary branches add avoidable length. Action granularity: Most statements perform one action, although nested C API calls in comprehensions require extra parsing. Reading flow: Consistent formatting and section markers support natural reading, but inverted conditions, inconsistent ptr/_ptr usage, and abbreviated internal names introduce friction. Overall, readable and maintainable, with conspicuous opportunities to simplify conditionals.