Sample
pyint-6a5a524ce773-I03
Replace names with length-matched meaningful but unrelated identifiers
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.345 | 0–1; higher is more readable |
| Mi | 0.738 | 0–1; higher is more readable |
| LLOC | 58 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 4.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 11 | 0–20; mean of three runs |
| BTTF | 0.534 | 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. | 3925.211 | −129.532 |
| Source linesThe number of non-empty source lines. | 195 | +78 |
| 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.048 | −6.072 |
Intercept 8.87 + feature contributions = -48.733 (log-odds).
Score = sigmoid(-48.733) = 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. | 196 | −5.903 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 168 | +5.074 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 168 | −3.434 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 194.987 | +2.316 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.053 | +0.422 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 75.342 | +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. | 76.959 | +0.406 |
Intercept 0.07 + feature contributions = -0.639 (log-odds).
Score = sigmoid(-0.639) = 0.345.
| Score | 0.738 |
|---|
| Score | 58 |
|---|
Run 1
The code has severe readability issues. The __init__ method uses meaningless parameter names (address, nextIndex, user, age, data, flag, etc.) that don't correspond to their semantic purpose - address maps to _default, tempValue to _converter, backupUser to on_setattr. This creates maximum confusion between parameter names and attribute assignments. The method names (fetchUser, release, findState) are obfuscated and don't reflect their actual behavior - fetchUser adds validators, release sets defaults, findState adds converters. The docstrings describe different functionality than what the code actually does. Parameter ordering follows no logical grouping, mixing 16 positional arguments that would be impossible to use correctly without reading the implementation. While the module imports and class structure show some organization, the mangled naming and misleading documentation destroy clarity of intent and reading flow.
Run 2
The code is difficult to read due to poor structure and naming. The class `_CountingAttr` has many attributes with cryptic names like `address`, `nextIndex`, `user`, `flag`, `tempValue`, etc., which obscure their purpose. The `__init__` method has over 15 parameters, making it long and hard to follow. Methods like `fetchUser`, `release`, and `findState` have misleading names unrelated to their actual behavior (validator, default, converter). The nesting is not deeply problematic, but the lack of clear intent and the mismatch between docstrings and implementation hurt clarity. The use of `Attribute` generation via a loop adds some conciseness but reduces readability. Overall, the code is functional but poorly named and structured, making it hard to maintain or understand.
Run 3
The code is severely obfuscated and poorly structured. Function/method names (fetchUser, release, findState) bear no relation to their documented purposes (validator, default, converter), violating clarity of intent. Parameter names in __init__ (address, nextIndex, user, age, data, flag, tempValue, etc.) are semantically meaningless and make the assignment block impossible to follow. The __init__ method performs 17 assignments in a flat but highly confusing sequence with no logical grouping or comments explaining mappings. The class attributes __attrs_attrs__ contains a large nested generator and tuple construction that is difficult to parse. Docstrings reference concepts like validators and defaults, but the actual code uses mismatched terminology. Overall the reading flow is unnatural, the code length is unnecessarily long for what it does, and the action granularity and structure obscure rather than reveal the logic.
Run 1
Code Structure: The class is logically divided into metadata, initialization, and decorator methods, but lengthy attribute declarations obscure the core behavior. Nesting: Mostly flat, with simple conditionals and one moderately nested comprehension. Clarity of intent: The main weakness is misleading names such as fetchUser, findState, and defaultAddress, plus constructor parameters unrelated to the fields they populate. Docstrings explain the intended behavior but reference meth rather than actual parameter names. Code length: Verbose metadata declarations and numerous imports add reading overhead; several imports are unused in this snippet. Action granularity: Statements generally perform one action per line, making assignments and control flow easy to follow. Reading flow: Conventional formatting and method separation help, but inconsistent naming styles, an unused age parameter, and references to definitions outside the snippet require readers to reconstruct context.
Run 2
Code Structure: The class is logically divided into attribute declarations, initialization, and decorator methods, but substantial setup obscures its core behavior. Nesting: Shallow conditionals and a single comprehension keep control flow manageable. Clarity of intent: The main weakness is misleading naming: constructor parameters such as address, user, and price map to unrelated attribute concepts, while fetchUser and findState do not describe their validator/converter roles. Docstrings clarify functionality but reference meth rather than actual parameter names. Code length: Repetitive Attribute configuration, numerous imports unused in this excerpt, and a lengthy constructor reduce concision; age is also unused. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Methods follow a consistent, straightforward pattern, but understanding initialization requires repeatedly translating arbitrary parameter names into meaningful fields, interrupting otherwise natural flow.
Run 3
Code Structure: The class is logically organized into metadata, initialization, and decorator methods, although the extensive metadata declaration dominates the snippet. Nesting: Control flow is shallow, with straightforward if/else branches; the metadata comprehension adds modest complexity. Clarity of intent: The main weakness is misleading names such as fetchUser, findState, address, and backupUser, which do not describe validation, conversion, or attribute configuration. Docstrings explain the actual behavior but reference meth rather than the named parameters. Code length: Repeated Attribute configuration and the long constructor make the code verbose; numerous imports are unused within this snippet. Action granularity: Most lines perform a single assignment or operation, making individual steps easy to inspect. Reading flow: Methods follow a natural check-update-return pattern, but tracing unrelated constructor parameter names to attribute fields creates substantial cognitive overhead. The unused age parameter further obscures intent.