Sample
pyint-d234b32600b9-I01
Remove comments and docstrings
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.35 | 0–1; higher is more readable |
| Mi | 0.64 | 0–1; higher is more readable |
| LLOC | 13 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 15.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.406 | 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. | 1099.534 | −36.285 |
| Source linesThe number of non-empty source lines. | 21 | +8.4 |
| 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.656 | −6.985 |
Intercept 8.87 + feature contributions = -25.999 (log-odds).
Score = sigmoid(-25.999) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 22 | +0.257 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 20.888 | −0.118 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.085 | +0.112 |
| 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. | 88 | −0.062 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 21 | −0.061 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 21 | −0.011 |
Intercept 0.07 + feature contributions = -0.617 (log-odds).
Score = sigmoid(-0.617) = 0.35.
| Score | 0.64 |
|---|
| Score | 13 |
|---|
Run 1
The code is reasonably readable. It has clear structure: imports are grouped logically, the class has a single method with a clear purpose, and the method's actions flow naturally. However, there are some readability issues: the spheroid assignment uses a conditional expression with 'or None' that, while concise, could be made clearer with a simple if statement. The code is moderately nested (only one indentation level) and maintains good action granularity, though the final return statement packs multiple operations into a single line. The expression '%(func)s %(op)s %(dist)s' uses string formatting that is somewhat obscure without prior knowledge. The method mixes template formatting with tuple concatenation, making the return statement dense. Overall, the code is understandable but could benefit from slightly more explicit logic in the spheroid check and cleaner separation of SQL template construction from parameter packing.
Run 2
The code is well-structured, with clear separation of logical operations into distinct steps. Nesting is minimal, with only a conditional expression and no deep indentation. Intent is clear: it builds a spatial distance lookup SQL expression. Length is appropriate—concise without sacrificing clarity. Action granularity is mostly one action per line, though the conditional expression packs multiple operations into one line, slightly reducing readability. Reading flow is natural, progressing from spheroid detection to expression compilation and final SQL assembly. Improvements could include breaking the conditional into multiple lines and adding a brief docstring or comments explaining 'spheroid' handling.
Run 3
The code demonstrates clear logical organization and maintains a flat structure with minimal nesting, which aids readability. The intent is fairly clear - it constructs a SQL expression for a distance lookup. However, the variable naming is somewhat cryptic (e.g., 'rhs_params', 'lhs', 'rhs', 'dist_sql'), assuming domain knowledge of Django ORM internals. The spheroid boolean assignment is clever but could be confusing to those unfamiliar with the 'or None' pattern. The code is concise overall, though the string formatting with multiple variables in a single expression reduces readability. Action granularity is reasonable but could be improved by separating the distance expression resolution into distinct steps. The reading flow is logical: computing spheroid, getting expression, compiling, processing distance, then returning the result. Overall, it is reasonably readable for experienced Django developers but less accessible to general developers due to ORM-specific terminology and somewhat dense expressions.
Run 1
Code Structure: The method is logically organized into distance-expression construction, compilation, distance processing, and SQL assembly. Nesting: It remains flat, with no nested control flow. Clarity of intent: Descriptive method and variable names communicate the purpose, though the spheroid condition ending in 'or None' is subtle, and the base class and supporting methods require external context. Code length: The implementation is concise; several imports appear unused in this snippet. Action granularity: Most statements perform one clear action, although expression resolution and compilation are combined on one line. Reading flow: Processing follows a natural sequence from inputs to SQL and parameters. Multiline formatting aids readability, but dictionary-based string interpolation and tuple unpacking add minor cognitive overhead.
Run 2
Code Structure: The method follows a logical sequence: determine spheroid handling, build the distance expression, compile it, process the threshold, and return SQL with parameters. Nesting: Flat control flow and minimal nesting make it easy to follow. Clarity of intent: Descriptive method and variable names communicate the purpose, although the spheroid-or-None idiom, positional parameter check, and externally defined base class require context. Code length: The implementation is concise, but the displayed imports appear unused in this snippet. Action granularity: Most statements perform one clear operation; expression resolution and compilation are combined on one line but remain understandable. Reading flow: Consistent formatting and sequential transformations support natural reading, though the dictionary-based SQL interpolation is slightly cumbersome.
Run 3
Code Structure: The method follows a logical sequence: determine spheroid handling, build and compile the distance expression, process the comparison distance, and return SQL with parameters. Nesting: Minimal nesting makes it easy to scan. Clarity of intent: Descriptive method and variable names communicate the purpose, though the boolean-or-None idiom, inherited attributes, and undefined-in-snippet DistanceLookupBase require context. Code length: The implementation is concise, but several imports appear unused in this snippet. Action granularity: Most statements perform one conceptual action; compiling and resolving the expression on one line slightly increases cognitive load. Reading flow: Execution proceeds naturally from configuration to SQL generation, with consistent formatting. Dictionary-based string interpolation adds minor visual complexity to the final return.