Sample
pyint-f5cf4d6e57d1-I05
Rewrite eligible decimal integer literals in hexadecimal notation
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.194 | 0–1; higher is more readable |
| Mi | 0.518 | 0–1; higher is more readable |
| LLOC | 117 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.182 | 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. | 7584.101 | −250.275 |
| Source linesThe number of non-empty source lines. | 228 | +91.2 |
| 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.407 | −6.61 |
Intercept 8.87 + feature contributions = -156.815 (log-odds).
Score = sigmoid(-156.815) = 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. | 229 | −7.072 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 181 | +5.523 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 181 | −3.733 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 227.898 | +2.776 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 85.86 | +0.581 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.051 | +0.445 |
| 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.943 | −0.017 |
Intercept 0.07 + feature contributions = -1.427 (log-odds).
Score = sigmoid(-1.427) = 0.194.
| Score | 0.518 |
|---|
| Score | 117 |
|---|
Run 1
The code is well-structured and highly readable. It has a clear class with logical method organization, minimal nesting, and concise docstrings explaining intent. Methods are focused and single-purpose, with good action granularity. The reading flow is natural, with properties and methods grouped logically. Minor deductions for some C API interactions using hexadecimal constants (0x0, 0x1, 0x4) which are slightly opaque, and occasional multi-step list comprehensions that could be split for clarity. Overall, the code demonstrates excellent readability through consistent naming, clear error handling, and proper separation of concerns.
Run 2
The code demonstrates strong readability through clear organization, minimal nesting, and consistent patterns. The class structure is logical, with a well-documented __init__ establishing ownership relationships, followed by dunder methods and a clean separation of properties and methods. Nesting is kept shallow through early returns and guard clauses. Each method has a focused purpose expressed through clear docstrings. Line length is reasonable, and complex operations are broken into comprehensions that read naturally. The use of 0x0 and 0x1 instead of 0 and 1 is slightly unusual but not detrimental. The _make_feature method's fallback loop could be slightly clearer with stronger error messaging, and the spatial_filter setter has multiple nested branches that slightly reduce flow. Overall, the code reads like well-maintained library code: explicit, purposeful, and accessible to developers familiar with GIS concepts. Minor opportunities exist for simplifying the spatial_filter validation and modernizing some type checking patterns.
Run 3
The code is well-structured with clear class-level organization, logical method grouping, and consistent use of properties and docstrings. Nesting is minimal and readable, with early returns and guard clauses. Intent is highly explicit through descriptive naming and concise comments. While some methods are moderately long, complexity is justified by underlying GDAL API interactions. Action granularity is appropriate—most lines perform one logical operation. Reading flow is natural, with helper methods and property blocks clearly delineated. Minor deductions for occasional magic numbers and dense list comprehensions, but overall readability is excellent.
Run 1
Code Structure: The class is logically organized into initialization, Python protocol methods, properties, and layer operations. Nesting: Most methods are flat, with only modest nesting in feature lookup and filter validation. Clarity of intent: Descriptive method names, docstrings, and explanatory comments make the wrapper's purpose clear; abbreviated C API names, hexadecimal constants, and mixed ptr/_ptr usage add friction. Code length: Methods are concise, although some comments repeat obvious behavior and field-property implementations are repetitive. Action granularity: Statements generally perform one action each; nested API calls and comprehensions occasionally combine several conceptual steps. Reading flow: Consistent formatting and section labels support natural navigation, but legacy property construction, redundant else branches after returns, and low-level pointer handling slightly interrupt the flow.
Run 2
Code Structure: Clearly organized into initialization, collection behavior, properties, and methods, with focused responsibilities. Nesting: Generally shallow; feature lookup and spatial-filter validation introduce only moderate nesting. Clarity of intent: Descriptive names, docstrings, and explanatory comments make the wrapper's purpose clear. However, hexadecimal constants for ordinary values, inconsistent ptr/_ptr usage, and dense C API expressions add cognitive overhead. Code length: Most methods are concise, though repetitive field-property implementations and some redundant comments increase length slightly. Action granularity: Statements generally perform one action each; nested API calls and conversion comprehensions occasionally combine several operations. Reading flow: Consistent formatting and logical ordering support natural reading, but mixing decorator-based properties with an explicit property constructor and retaining unnecessary else branches slightly disrupt consistency.
Run 3
Code Structure: Well-organized class with initialization, Python protocol methods, properties, and utility methods clearly grouped. Nesting: Mostly shallow; feature lookup and spatial-filter validation introduce only modest nesting. Clarity of intent: Descriptive method names, docstrings, and explanatory comments make the wrapper's purpose clear. However, hexadecimal constants for ordinary values, abbreviated internal names, inconsistent ptr/_ptr usage, and the parameter named filter slightly reduce clarity. Code length: Methods are concise, although repetitive field-access properties and some redundant comments add length. Action granularity: Statements generally perform one action per line; nested API calls and comprehensions occasionally combine several operations. Reading flow: Consistent formatting and logical ordering support natural reading, with minor interruptions from legacy property construction and low-level GDAL details.