Sample
pyint-dae92ba1d776-I02
Shorten method, parameter, and local names without collisions
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.476 | 0–1; higher is more readable |
| Mi | 0.48 | 0–1; higher is more readable |
| LLOC | 74 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 6.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 10.67 | 0–20; mean of three runs |
| BTTF | 0.352 | 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. | 5663.841 | −186.907 |
| Source linesThe number of non-empty source lines. | 144 | +57.6 |
| 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.481 | −6.721 |
Intercept 8.87 + feature contributions = -127.158 (log-odds).
Score = sigmoid(-127.158) = 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. | 145 | −4.098 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 135 | +3.932 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 135 | −2.677 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 143.855 | +1.601 |
| 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. | 74.972 | +0.49 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 70.841 | +0.339 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.072 | +0.247 |
Intercept 0.07 + feature contributions = -0.096 (log-odds).
Score = sigmoid(-0.096) = 0.476.
| Score | 0.48 |
|---|
| Score | 74 |
|---|
Run 1
This code is extremely difficult to read due to heavily obfuscated naming conventions. Identifiers like 'wid', 'rel2', 'can2', 'can3', 'can4', 'sup', 'cas', 'inf2', 'get2', 'value2', 'value3', 'id2', 'is2', 'med', and 'cho2' provide no semantic meaning, making the purpose of parameters, methods, and variables ambiguous. The logic, while not deeply nested, suffers from unclear intent as a result. The action granularity is mostly reasonable, but the reading flow is completely disrupted by the cryptic abbreviations. Code length is acceptable, and the structure follows a standard class wrapper pattern, but these positives are overwhelmed by the severe naming issues. This code would require significant effort to understand and maintain, scoring very low on clarity of intent and reading flow.
Run 2
The code suffers from heavily obfuscated naming (e.g., `wid`, `rel2`, `can2`, `get2`, `value3`, `id2`), which severely reduces clarity of intent and reading flow. The `__init__` method packs multiple unrelated checks into compact, cryptically named assignments. While the structure is functionally grouped and nesting is shallow, the abbreviated parameter and method names force the reader to infer meaning from context or comments. The `get2` method is particularly cluttered, building a large context dictionary with similarly unclear keys. Some positives: it has docstrings, organized imports, and one-action-per-line in parts, but they are outweighed by the pervasive name shortening and slightly convoluted logic (e.g., backwards compatibility checks without explanation in the method signature).
Run 3
The code heavily relies on cryptic abbreviations and shortened names (e.g., 'wid', 'rel2', 'can2', 'get2', 'med', 'cho2', 'is2', 'inf', 'nam', 'val2'), which severely obscures the intent and makes it hard to follow. While the code structure is somewhat organized and each line generally performs a single action, the unclear naming, unexplained boolean parameters, and methods like 'get2' make it feel disorganized and require significant mental effort to decode. Some comments exist but don't compensate for the overall poor readability.
Run 1
Code Structure: The class is logically divided into initialization, properties, context construction, and delegation methods, though several imports appear unused. Nesting: Mostly flat, with simple conditionals and no deeply nested control flow. Clarity of intent: The class name, comments, and descriptive attribute names help, but cryptic identifiers such as can2, rel3, get2, and value3 obscure method purposes and parameter meanings. The @choices.setter reference does not match the declared cho2 property, further disrupting comprehension. Code length: Generally reasonable, although numerous thin delegation methods and awkward line wrapping add visual overhead. Action granularity: Most lines perform a single clear operation; compact boolean expressions remain manageable. Reading flow: Initialization and context assembly follow a natural sequence, but inconsistent naming forces readers to repeatedly trace variables and infer intended interfaces.
Run 2
Code Structure: The class is logically organized into initialization, properties, context construction, and delegation methods, although numerous unused imports add clutter. Nesting: Control flow is shallow, with simple conditionals and no deeply nested blocks. Clarity of intent: The docstring and comments help, but cryptic names such as wid, rel2, can2, get2, and value3 obscure parameter roles and method purposes. The @choices.setter reference does not match the defined cho2 property, further confusing the interface. Code length: Mostly concise, though repetitive delegation methods and awkward wrapping introduce some overhead. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Initialization and context assembly proceed naturally, but inconsistent naming, numbered identifiers, and the mismatched property decorator interrupt comprehension and require readers to infer intended Django conventions.
Run 3
Code Structure: The class is logically divided into initialization, properties, context construction, and delegation methods, though unrelated imports add clutter. Nesting: Mostly flat, with simple conditionals and no deeply nested control flow. Clarity of intent: The docstring, comments, and descriptive instance attributes help, but names such as wid, rel2, can2, get2, and value3 obscure purpose. The @choices.setter reference does not match the cho2 property, further confusing the interface. Code length: Generally reasonable, although unused imports and awkwardly wrapped expressions introduce unnecessary bulk. Action granularity: Statements typically perform one action per line, and the context dictionary is clearly formatted. Reading flow: Initialization and context assembly follow a sensible sequence, but cryptic naming and inconsistent property names repeatedly force readers to infer meaning.