Sample
pyint-383da6ce2d1e-I13
Lower every eligible synchronous for loop to a while loop
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 | 13.67 | 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 structured but has readability issues. The DistanceLookupFromFunction class has a single method with moderate complexity. The `spheroid` variable uses a tuple comparison that's somewhat convoluted, making intent unclear. The method chains multiple operations like `resolve_expression` and `compiler.compile`, which compresses several actions. Variable naming is adequate but not self-documenting. The return statement combining string formatting and tuple unpacking is dense. Nesting is minimal, which is good, but the logic would benefit from breaking into smaller, named steps to improve clarity of intent and action granularity.
Run 2
The code is well-structured and readable, with logical organization of operations within a single method. Nesting is flat, with clear variable assignments and a straightforward return statement. The intent is clear at a high level—building a spatial distance lookup SQL expression—though some domain-specific details, like the spheroid parameter handling, may require context. Code length is concise, avoiding unnecessary verbosity. Action granularity is mostly one action per line, though the return statement packs multiple operations into a tuple construct, slightly reducing readability. The reading flow is natural, following a logical sequence: determine spheroid, build distance expression, compile it, process distance, and return the final SQL and parameters. Minor deductions come from the somewhat dense string formatting in the return and the implicit conditional assignment for spheroid, which could be more explicit for clarity.
Run 3
The code is structured but has significant readability issues. The `DistanceLookupFromFunction` class is logically organized, but the `as_sql` method mixes multiple responsibilities: determining spheroid, resolving and compiling expression, processing distance, and formatting the SQL string. The nesting is shallow, which is good, but the intent is obscured by a heavy reliance on Django's internal APIs (`compiler.compile`, `resolve_expression`, `process_distance`), making it hard to understand without deep framework knowledge. The conditional expression for `spheroid` is difficult to parse due to its inline condition with an `or None` trap. The long chained expression `distance_expr.resolve_expression(compiler.query)` and the multi-line return tuple with string formatting reduce clarity. Variable names like `dist_sql`, `dist_params`, and `*params` are terse. The reading flow is disjointed because the reader must jump between method calls to understand the data transformation. Overall, the code is functional but not easily scannable or self-explanatory.
Run 1
Code Structure: The method is logically organized into determining spheroid usage, constructing and compiling a distance expression, processing the comparison distance, and returning SQL with parameters. Nesting: Minimal nesting and no control-flow blocks make it easy to follow. Clarity of intent: Descriptive method and variable names convey the purpose, though the boolean-or-None idiom and positional rhs_params check require interpretation. DistanceLookupBase is not defined or imported in this snippet, limiting standalone understanding. Code length: The method is concise, but the visible imports are unused and add clutter. Action granularity: Most statements perform one conceptual action, although compiling and resolving the expression occur on the same line. Reading flow: Sequential processing is natural, and multiline formatting supports readability; the final dictionary-based string interpolation is slightly dense.
Run 2
Code Structure: The method follows a logical sequence: determine the spheroid option, build and compile the distance expression, process the comparison distance, and return SQL with parameters. Nesting: Flat execution with no nested control flow; parentheses only group expressions. Clarity of intent: Descriptive method and variable names convey the purpose, though the boolean-or-None idiom and reliance on framework APIs require familiarity. The base class is not defined or imported in the snippet. Code length: The method is concise, but the displayed imports are unused. Action granularity: Most statements perform one coherent action, although expression resolution and compilation are combined. Reading flow: Natural top-to-bottom progression with sensible line breaks; abbreviated SQL variables and inline string interpolation add minor reading effort.
Run 3
Code Structure: The method is logically organized into determining spheroid behavior, constructing and compiling the distance expression, processing the distance, and returning SQL with parameters. Nesting: Flat control flow makes it easy to follow. Clarity of intent: Descriptive method and variable names convey the purpose, though the boolean-or-None spheroid expression is slightly subtle, and DistanceLookupBase is not defined or imported in the snippet. Code length: The implementation is concise, although the shown imports appear unused. Action granularity: Most statements perform one coherent action; compiling a resolved expression combines two closely related operations. Reading flow: Execution proceeds naturally from configuration to SQL generation, with sensible line wrapping. A blank line separating imports from the class more clearly and a brief explanation of the spheroid sentinel would improve readability.