Sample
pyint-feaf5e150d22-SRC
Unmodified source class
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.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 generally readable with a clear structure: it defines a class with a single method that handles SQL generation. The method is flat, containing no nested conditionals or loops, and each line performs a distinct action. Variable names like 'spheroid', 'distance_expr', and 'dist_sql' clearly convey intent. However, readability is slightly reduced by the moderately complex boolean expression on the first line (which returns None or a boolean) and the tuple unpacking/repacking at the end, which requires careful reading. The percentage-format string on the return statement also adds minor cognitive overhead compared to f-strings. Overall, the code is concise and logically organized, with good action granularity and a natural reading flow, though a brief comment explaining the spheroid logic would improve clarity.
Run 2
The code demonstrates poor readability due to several factors. The `as_sql` method combines multiple operations: spheroid detection with a confusing ternary expression that returns None as a fallback, expression resolution, and SQL string formatting. The variable names are abbreviated (`sql`, `dist_sql`, `dist_params`) reducing clarity. The return statement packs SQL string formatting and tuple concatenation into a single complex expression. The `spheroid` assignment is particularly unclear—using `or None` creates ambiguity about intent. While the method logically groups related operations, it lacks intermediate explanatory steps or comments, making the flow difficult to follow. The use of `%` string formatting with keyword arguments in a single line adds cognitive overhead. Overall, the code requires significant mental parsing to understand each step's purpose.
Run 3
The code is relatively clear and concise. It defines a custom lookup's SQL generation in a straightforward way, with a logical structure. The spheroid determination is slightly terse (using `or None`) but understandable. Variable names like `distance_expr`, `sql`, `params`, and `dist_sql` clearly indicate their purpose. Nesting is minimal; the function stays flat. Action granularity is mostly one action per line, though the return statement packs multiple operations into the formatting and tuple creation, slightly impacting readability. The reading flow is natural, moving from determining the spheroid flag, to compiling the distance expression, to processing the distance, and finally constructing the SQL and parameters. The code could be slightly improved by splitting the spheroid logic or the return tuple composition, but overall it is well-structured and easy to follow for someone familiar with Django's ORM internals.
Run 1
Code Structure: The method follows a logical sequence: determine spheroid behavior, build and compile the distance expression, process the comparison distance, and return SQL with parameters. Nesting: Very shallow, with no nested control-flow blocks. Clarity of intent: Descriptive method and variable names make the purpose clear, although the boolean-or-None expression and reliance on an undefined-in-snippet base class require context. Code length: The method is concise, but several imports appear unused in this snippet. Action granularity: Most statements perform one coherent action; compiling a resolved expression combines two operations but remains understandable. Reading flow: Execution proceeds naturally from preparation to output, and multiline formatting improves readability. The SQL interpolation and parameter unpacking are compact without being excessively dense.
Run 2
Code Structure: The method follows a logical sequence: determine spheroid usage, build and compile the distance expression, process the comparison distance, and return SQL with parameters. Nesting: Flat control flow with no nested branches or loops. Clarity of intent: Descriptive method and variable names clarify the SQL-generation purpose, although the boolean-or-None idiom and externally defined DistanceLookupBase require contextual knowledge. Code length: The method is concise, but the displayed imports are 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: The progression is natural, with readable multiline calls and a clearly grouped return value. The SQL interpolation is understandable but somewhat visually dense.
Run 3
Code Structure: Logically organized into a focused class method, though the base class is not defined or imported in the snippet and several imports are unused. Nesting: Flat execution with no nested control flow; multiline expressions are easy to follow. Clarity of intent: Names clearly communicate distance-lookup SQL generation, but the spheroid flag's False-to-None conversion and framework-specific methods require context. Code length: The method is concise without excessive boilerplate, although unused imports add clutter. Action granularity: Each statement performs a distinct step, with compilation and expression resolution combined in one readable line. Reading flow: Naturally progresses from determining options to building the distance expression, compiling SQL, processing the comparison distance, and returning SQL with parameters.