Sample
pyint-4c5b4a4b5dfd-SRC
Unmodified source class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.193 | 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.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17.67 | 0–20; mean of three runs |
| BTTF | 0.367 | 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.402 | −6.603 |
Intercept 8.87 + feature contributions = -156.808 (log-odds).
Score = sigmoid(-156.808) = 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.444 |
| 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.952 | −0.018 |
Intercept 0.07 + feature contributions = -1.428 (log-odds).
Score = sigmoid(-1.428) = 0.193.
| Score | 0.518 |
|---|
| Score | 117 |
|---|
Run 1
The code is highly readable. It follows a clear class structure with logical grouping: initialization, dunder methods, properties, and methods are well-organized. Each method/property has a docstring explaining its purpose. Nesting is minimal—only at necessary points like isinstance checks and try/except blocks. Lines are concise and focused, with one main action per line. The code makes good use of list comprehensions and helper methods to avoid repetition. Variable names are descriptive, and the code uses appropriate whitespace. The reading flow is natural, progressing from simple accessors to more complex operations. Minor deductions: some complex one-liners in list comprehensions could be broken up, and a few method implementations rely on understanding the GDAL C API. Overall, this is an excellent example of readable, maintainable code.
Run 2
The code is highly readable with clear structure and intent. It organizes a complex GDAL wrapper into logical sections (properties, methods, helpers) and uses consistent docstrings and naming conventions. Nesting is generally shallow, though the `__getitem__` method has moderate branching. Action granularity is mostly one action per line, with some list comprehensions that remain clear. The code leverages Python idioms like properties and iteration, improving readability. A few minor issues slightly reduce clarity: some comments repeat what the code already shows, and methods like `_make_feature` have nested conditionals that require careful reading. Overall, the code is maintainable and easy to follow.
Run 3
The code is highly readable with clear structure, consistent patterns, and excellent documentation. It follows logical organization with properties grouped together, private helper methods separated, and public methods at the end. Nesting is minimal—only a few conditional branches and list comprehensions. Intent is clear through descriptive method names, docstrings, and inline comments. Code length is appropriate; each method is focused and concise without unnecessary repetition. Action granularity is generally one action per line, with list comprehensions used effectively for simple patterns. The reading flow is natural: imports → class definition → init → dunder methods → helper methods → properties → public methods. Minor deductions: some list comprehensions could be slightly more readable if extracted to helper methods, and a few methods (like _make_feature) have slightly longer logical paths. The use of type hints is absent, but this is typical for older Django code. Overall, exemplary readability with strong documentation throughout.
Run 1
Code Structure: Well-organized class with initialization, Python protocol methods, properties, and layer operations clearly grouped. Nesting: Mostly shallow; feature lookup and spatial-filter validation introduce only moderate nesting. Clarity of intent: Descriptive method names, docstrings, and explanatory comments make responsibilities clear, though abbreviated C API names, inconsistent ptr/_ptr usage, and nested API calls require domain knowledge. Code length: Appropriate for the functionality, with small methods; some repetitive property implementations and redundant comments add minor verbosity. Action granularity: Statements generally perform one action per line, although nested calls and comprehensions combine retrieval, conversion, and construction. Reading flow: Natural progression and consistent formatting support easy scanning. Minor distractions include legacy property construction, unnecessary else branches after returns, and a force parameter on a property getter that looks caller-configurable but is not accessible through normal property usage.
Run 2
Code Structure: Well-organized class with focused methods and clearly grouped properties and operations. Nesting: Generally shallow; indexing, feature lookup, and filter validation introduce only modest nesting. Clarity of intent: Descriptive method names, docstrings, and explanatory comments make the wrapper's purpose clear, though abbreviated C API names and inconsistent ptr/_ptr usage require extra attention. Code length: Most methods are concise, but repetitive field-property implementations and some redundant comments add length. Action granularity: Statements generally perform one action each; nested API calls in comprehensions compress several operations and slightly reduce readability. Reading flow: Initialization, Python protocol methods, properties, and public operations follow a natural progression. Minor distractions include mixing property declaration styles, shadowing the built-in filter name, and exposing a force parameter on a property getter.
Run 3
Code Structure: Well-organized class with focused methods and clearly grouped properties and operations. Nesting: Generally shallow; indexing, feature lookup, and spatial-filter validation introduce only modest nesting. Clarity of intent: Descriptive method names, docstrings, and useful comments explain both behavior and GDAL-specific constraints. Abbreviations such as _ldefn and capi, inconsistent ptr/_ptr usage, and nested C API calls slightly reduce clarity. Code length: Appropriately concise for the functionality, though some comments repeat obvious actions and field-access properties contain repetitive patterns. Action granularity: Most statements perform one clear action; comprehensions and nested calls occasionally combine retrieval, conversion, and wrapping. Reading flow: Imports, initialization, special methods, properties, and public operations follow a natural progression. Minor distractions include redundant else branches after returns, the parameter named filter shadowing a built-in, and the unusual optional argument on the num_feat property.