Sample
pyint-76d0396aa4c6-I04
Replace names with deterministic minifier-style shortest identifiers
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.188 | 0–1; higher is more readable |
| Mi | 0.617 | 0–1; higher is more readable |
| LLOC | 117 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 3.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 11 | 0–20; mean of three runs |
| BTTF | 0.115 | 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. | 7697.363 | −254.013 |
| Source linesThe number of non-empty source lines. | 228 | +91.2 |
| 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.402 | −6.603 |
Intercept 8.87 + feature contributions = -160.545 (log-odds).
Score = sigmoid(-160.545) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 229 | −7.072 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 181 | +5.523 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 181 | −3.733 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 227.852 | +2.775 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 85.86 | +0.581 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.055 | +0.411 |
| 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. | 86.956 | −0.018 |
Intercept 0.07 + feature contributions = -1.461 (log-odds).
Score = sigmoid(-1.461) = 0.188.
| Score | 0.617 |
|---|
| Score | 117 |
|---|
Run 1
The code is severely obfuscated and nearly unreadable due to meaningless single-letter variable and method names (e.g., 'a', 'b', 'q', 's', 'r', 't') replacing descriptive identifiers. This destroys clarity of intent, reading flow, and code structure since readers cannot infer what any component does without extensive reverse-engineering. Nesting is moderate and action granularity is acceptable, but those positives are overwhelmed by the naming choices. The docstrings provide some context, but they are undermined by methods like 'm()' for get_spatial_filter and 'n()' for set_spatial_filter. Property names 'b' through 'l' contain no semantic meaning, making code length effectively longer than necessary due to required cross-referencing. Overall, this code would be extremely difficult to maintain or review despite being syntactically valid.
Run 2
The code is highly obfuscated. Meaningful names (Layer, random_read, extent, name, num_features, etc.) are replaced with meaningless single-letter identifiers (a, b, c, d, q, r, s, t, A, B, C, etc.), making the purpose of every method, property, and variable impossible to discern without deep reverse-engineering. While the original structure may have been logical, the renaming destroys clarity of intent and disrupts natural reading flow. Nesting and structure appear moderately flat, but action granularity suffers because the dense list comprehensions and calls hide multiple operations. The code is also unnecessarily long due to verbose docstrings that now describe obfuscated names inconsistently. Overall, this appears deliberately unreadable.
Run 3
This code is severely obfuscated and virtually unreadable. While it has some structure (clear method grouping with comments), the author has intentionally or carelessly replaced all meaningful variable names with single letters and unrelated characters (r, s, t, u, v, w, A, B, C, D, etc.). This destroys clarity of intent, making it impossible to understand what each parameter or variable represents without reverse-engineering the logic. Method names like 'a', 'b', 'c', 'o', 'p', 'q' provide zero semantic information. The nesting is moderate but the reading flow is completely broken—readers must constantly map meaningless letters to guessed purposes. Code length is acceptable and each line typically performs one action, but these positives are negated by the cryptic naming. Even the docstrings, though helpful, only partially mitigate the confusion. This code would be extremely difficult to maintain or review.
Run 1
Code Structure: The class is logically organized into initialization, indexing, properties, and methods, but spatial_filter references undefined accessor names rather than m and n, disrupting coherence. Nesting: Generally shallow, with manageable conditionals and loops. Clarity of intent: Docstrings and descriptive C API calls explain functionality, but single-letter method, property, parameter, and variable names severely obscure meaning and require repeated cross-referencing. Code length: Most implementations are concise; documentation adds useful context, though some comments repeat obvious operations. Action granularity: Statements generally perform one action per line, while nested API calls and comprehensions occasionally combine several operations. Reading flow: Consistent formatting and section markers support navigation, but opaque references such as self.a, self.d, and self.h interrupt otherwise natural flow. Overall, readable organization is substantially undermined by naming and the inconsistent property declaration.
Run 2
Code Structure: The class is logically divided into initialization, indexing, properties, and methods, but spatial_filter references undefined accessors rather than m and n, disrupting coherence. Nesting: Mostly shallow, with manageable conditional branches and loops. Clarity of intent: Docstrings and descriptive GDAL API calls explain functionality, but single-letter method, property, and variable names obscure meaning and force repeated cross-referencing. Code length: Most methods are concise; documentation adds useful context, although some comments repeat obvious operations. Action granularity: Generally one action per line, with conventional comprehensions; nested API calls occasionally increase cognitive load. Reading flow: Consistent formatting and grouping help, but opaque references such as self.a, self.d, and self.h substantially interrupt natural reading.
Run 3
Code Structure: The class is logically organized into initialization, collection behavior, properties, and methods, but spatial_filter references undefined accessor names rather than m and n. Nesting: Generally shallow, with only modest nesting in indexing, feature lookup, and filter validation. Clarity of intent: Docstrings and descriptive GDAL API calls explain much of the behavior, but single-letter method, property, parameter, and variable names severely obscure meaning and force repeated cross-referencing. Code length: Most methods are concise; documentation adds useful context, although some comments repeat obvious operations. Action granularity: Statements generally perform one action each, while comprehensions and nested API calls compact related operations reasonably. Reading flow: Consistent formatting and logical grouping support navigation, but expressions such as self.a(t), self.d, and self.h interrupt natural comprehension. Overall, the implementation has readable structural foundations, substantially weakened by opaque naming and inconsistent accessor references.