Sample
pyint-3d07708e0cff-I10
Deterministically remove some optional blank lines and bracketed line breaks
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.078 | 0–1; higher is more readable |
| Mi | 0.516 | 0–1; higher is more readable |
| LLOC | 117 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 12.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.321 | 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. | 210 | +84 |
| 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.398 | −6.597 |
Intercept 8.87 + feature contributions = -164.002 (log-odds).
Score = sigmoid(-164.002) = 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. | 211 | −6.435 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 163 | +4.901 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 163 | −3.32 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 209.904 | +2.524 |
| 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. | 133.981 | −2.01 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 133.991 | +1.357 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.051 | +0.445 |
Intercept 0.07 + feature contributions = -2.466 (log-odds).
Score = sigmoid(-2.466) = 0.078.
| Score | 0.516 |
|---|
| Score | 117 |
|---|
Run 1
The code is generally well-structured with clear class organization and docstrings, but readability suffers from several issues. The class follows a logical pattern with properties and methods grouped together, and comments explain complex logic like random access fallback. However, there are multiple formatting problems: missing blank lines between methods, inconsistent indentation in list comprehensions (particularly in fields, field_types, and field_precisions methods), and awkward line breaks that disrupt reading flow. Some lines try to accomplish too much, especially in the list comprehensions where function calls are split across lines with odd spacing. The __getitem__ method handles three cases cleanly but the slice handling line is dense. The spatial filter setter has reasonable validation logic but could be broken into smaller helper methods. Overall, the code is functional and the intent is clear, but it needs consistent formatting and better line organization to be truly readable.
Run 2
The code is generally clear and well-structured, with logical class organization and good use of docstrings and comments. However, several readability issues exist: inconsistent blank lines between methods, occasional long or misaligned lines (e.g., in fields and field_types properties), and inconsistent indentation/line breaks in list comprehensions. Some methods are slightly dense, and the overall flow feels uneven due to these formatting inconsistencies. The purpose of each method is clear, and naming is descriptive, which improves clarity. The class is not deeply nested and each action is mostly separated per line, but a few comprehensions pack multiple operations into one line. Overall readable but would benefit from more consistent PEP 8 formatting and cleaner line breaks.
Run 3
While the code follows a logical class structure with docstrings and grouped sections, readability is significantly compromised by several factors. Deep nesting occurs in methods like __getitem__ and _set_spatial_filter, adding cognitive load. There is inconsistent code formatting and alignment, particularly in list comprehensions within the properties for fields, field_types, and field_precisions, which disrupts the reading flow. Some lines are excessively long and contain multiple actions, violating the principle of action granularity. Additionally, the code has unnecessary mixed-case abstractions and a dense use of C API calls, making it harder to discern intent at a glance. Though variable names are descriptive and organization is decent, the inconsistency and clutter reduce overall clarity. The code is maintainable but not highly readable in its current form.
Run 1
Code Structure: The class is logically organized into initialization, iteration/indexing, properties, and methods, with focused responsibilities. Nesting: Generally shallow; feature lookup and spatial-filter validation introduce only moderate nesting. Clarity of intent: Descriptive method names, docstrings, and explanatory comments make behavior clear, although C API abbreviations and inconsistent ptr/_ptr usage add cognitive overhead. Code length: Appropriate for the wrapper's functionality, with concise methods and comprehensions; some documentation is slightly verbose. Action granularity: Most lines perform one action, but nested API calls and crowded comprehensions combine several operations. Reading flow: The overall sequence is natural, but missing blank lines between methods, irregular spacing, and malformed-looking line wrapping noticeably disrupt scanning.
Run 2
Code Structure: The class is logically organized into initialization, protocol methods, properties, and layer operations, with focused helper methods. Nesting: Generally shallow; feature lookup and spatial-filter validation introduce only moderate nesting. Clarity of intent: Descriptive method names, docstrings, and explanatory comments make the wrapper's purpose clear, although abbreviated C API names and inconsistent ptr/_ptr usage require additional context. Code length: Most methods are concise; some comments repeat obvious operations, but overall length is appropriate for the functionality. Action granularity: Statements generally perform one action, though nested API calls and compressed comprehensions increase parsing effort. Reading flow: The overall sequence is natural, but missing blank lines between methods, irregular spacing, and poorly formatted multiline expressions noticeably interrupt scanning.
Run 3
Code Structure: Logically organized into a cohesive Layer class with initialization, iteration, properties, and utility methods. Nesting: Generally shallow; feature lookup and spatial-filter validation introduce only moderate nesting. Clarity of intent: Descriptive method names and helpful docstrings explain the wrapper's purpose and important GDAL behavior, although abbreviated C API names require domain knowledge. Code length: Most methods are concise, with some repetitive property implementations and verbose comments. Action granularity: Statements generally perform one action each, though nested API calls and crowded comprehensions require extra parsing. Reading flow: The overall progression is natural, but inconsistent blank lines, excessive inline whitespace, and awkwardly formatted comprehensions interrupt scanning. Consistent formatting and clearer separation between methods would substantially improve readability.