Sample
pyint-d2a74796556d-I02
Shorten method, parameter, and local names without collisions
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.361 | 0–1; higher is more readable |
| Mi | 0.53 | 0–1; higher is more readable |
| LLOC | 13 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 3.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 13 | 0–20; mean of three runs |
| BTTF | 0.356 | 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. | 1106.954 | −36.529 |
| 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.662 | −6.993 |
Intercept 8.87 + feature contributions = -26.253 (log-odds).
Score = sigmoid(-26.253) = 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.907 | −0.118 |
| 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. | 84.955 | +0.067 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 21 | −0.061 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.094 | +0.027 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 21 | −0.011 |
Intercept 0.07 + feature contributions = -0.573 (log-odds).
Score = sigmoid(-0.573) = 0.361.
| Score | 0.53 |
|---|
| Score | 13 |
|---|
Run 1
This code is highly unreadable. The method 'as2' and parameters 'com', 'con', 'sph', 'sql2', 'par', 'dist', 'dist2' are cryptic abbreviations that obscure intent. Logic is tangled: the 'sph' variable is set to a boolean or None, then passed as 'spheroid' without explanation. Multiple operations (compile, resolve_expression, process_distance) are chained inline, and the return statement mixes string formatting with tuple unpacking in a single expression. Nesting is low, but action granularity is poor — several distinct operations occur on one line. Reading flow is disorganized, requiring significant effort to trace what the function does. Only the imports are clear. Overall, the code lacks clarity, meaningful naming, and logical separation of concerns.
Run 2
The code is extremely difficult to read due to cryptic naming conventions (com, con, sph, par, dist, dist2), ambiguous abbreviations, and inconsistent variable names. The method name 'as2' provides no meaningful context about its purpose or behavior. Multiple actions are packed into single lines, such as the boolean expression with 'or None' on one line and the dictionary-based string formatting combined with tuple unpacking in the return statement. The logic is tangled - the 'sph' variable creation is particularly confusing as it either returns a boolean or None without clear intent. The reading flow is poor as the code jumps from boolean logic to expression compilation to distance processing with no logical progression or explanatory comments. While the code is concise, it sacrifices clarity for brevity. The indentation and basic structure are present, but the overall readability is severely compromised by the poor naming and dense, multi-purpose statements.
Run 3
This code suffers from poor readability across multiple dimensions. The method signature uses cryptic abbreviations ('com', 'con', 'sql2', 'par', 'dist', 'dist2'), obscuring intent. The logic is compacted into a single method performing multiple unrelated operations: distance expression resolution, SQL compilation, and distance processing. Variable names are ambiguous and do not convey their roles. The inline conditional assignment for 'sph' reduces clarity, and the final string formatting with a dictionary is unnecessarily complex. The code lacks docstrings or comments explaining the transformation. Despite being relatively short, the density of operations and opaque naming make it difficult to follow. The flat structure is a minor positive, but it does not compensate for the overall lack of clarity and maintainability.
Run 1
Code Structure: The method follows a logical sequence: determine spheroid mode, build and compile a distance expression, process the comparison distance, and return SQL with parameters. However, the base class is not defined in the snippet, and several imports appear unused. Nesting: Minimal nesting makes the method easy to scan. Clarity of intent: Spatial distance comparison is recognizable, but names such as as2, com, con, sph, sql2, par, and dist2 obscure roles and require contextual knowledge. Code length: The implementation is concise, although some line breaks add visual bulk. Action granularity: Most statements perform one coherent action; the nested resolve_expression call slightly compresses multiple steps. Reading flow: Execution proceeds naturally from setup to output, but abbreviated naming and the formatted SQL return slow comprehension.
Run 2
Code Structure: The method is logically organized into spheroid detection, distance-expression construction, compilation, and SQL assembly, though the base class is not defined or imported in the snippet and several imports are unused. Nesting: Minimal nesting makes control flow easy to follow. Clarity of intent: GIS distance lookup processing is apparent, but names such as as2, com, con, sph, par, dist, and dist2 obscure roles and distinctions. The use of 'or None' also requires interpretation. Code length: The implementation is concise without substantial redundancy, although unused imports add noise. Action granularity: Most statements perform one logical action; the nested resolve_expression call and final formatting expression combine a few operations. Reading flow: Execution proceeds naturally from configuration to expression preparation and output, but cryptic naming and dense SQL formatting interrupt readability.
Run 3
Code Structure: The method follows a logical sequence: determine spheroid usage, build and compile a distance expression, process the comparison distance, and return SQL with parameters. However, the base class is not defined or imported in the snippet, and several imports appear unused. Nesting: Minimal nesting makes the method easy to scan. Clarity of intent: The class name communicates its purpose, but names such as as2, com, con, sph, sql2, par, dist, and dist2 obscure roles and relationships. The use of 'or None' also requires interpretation. Code length: Compact without substantial unnecessary implementation, though unused imports add noise. Action granularity: Most statements perform one coherent action; expression resolution and compilation are combined but remain manageable. Reading flow: Generally natural and sequential, with readable line breaks, but abbreviated naming and the distinction between similarly named distance variables interrupt comprehension.