Sample

pyint-feaf5e150d22-SRC

Unmodified source class

Lines21

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Dorn0.350–1; higher is more readable
Mi0.640–1; higher is more readable
LLOC13Logical lines; fewer is more readable
DeepSeek V4 Pro13.330–20; mean of three runs
GPT-6.1 Sol170–20; mean of three runs
BTTF0.4060–1; higher is more readable

Views

Source code

from django.contrib.gis.db.models.fields import BaseSpatialField from django.contrib.gis.measure import Distance from django.db import NotSupportedError from django.db.models import Expression, Lookup, Transform from django.db.models.sql.query import Query from django.utils.regex_helper import _lazy_re_compile class DistanceLookupFromFunction(DistanceLookupBase): def as_sql(self, compiler, connection): spheroid = ( len(self.rhs_params) == 2 and self.rhs_params[-1] == "spheroid" ) or None distance_expr = connection.ops.distance_expr_for_lookup( self.lhs, self.rhs, spheroid=spheroid ) sql, params = compiler.compile(distance_expr.resolve_expression(compiler.query)) dist_sql, dist_params = self.process_distance(compiler, connection) return ( "%(func)s %(op)s %(dist)s" % {"func": sql, "op": self.op, "dist": dist_sql}, (*params, *dist_params), )

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(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

FeatureValueContribution
(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.

Score0.64
Score13
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.