Sample
pyint-d1680f2a3435-I02
Shorten method, parameter, and local names without collisions
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.022 | 0–1; higher is more readable |
| Mi | 0.604 | 0–1; higher is more readable |
| LLOC | 145 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 5.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 11 | 0–20; mean of three runs |
| BTTF | 0.35 | 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. | 9090.297 | −299.98 |
| Source linesThe number of non-empty source lines. | 298 | +119.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.431 | −6.647 |
Intercept 8.87 + feature contributions = -178.557 (log-odds).
Score = sigmoid(-178.557) = 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. | 299 | −9.55 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 198 | +6.111 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 198 | −4.123 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 297.859 | +3.754 |
| 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. | 126.963 | −1.712 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 126.98 | +1.244 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.053 | +0.426 |
Intercept 0.07 + feature contributions = -3.78 (log-odds).
Score = sigmoid(-3.78) = 0.022.
| Score | 0.604 |
|---|
| Score | 145 |
|---|
Run 1
The code suffers from severe readability problems primarily due to non-descriptive, numbered identifiers (get2, set2, ite, ite2, ite3, ite4, list2, list3, get3, set3, upd, fin, get4) and similarly numbered parameter names (nam, nam2, nam3, etc.). This obscures intent and forces the reader to constantly cross-reference documentation. While the class structure is logical and methods are relatively short, the naming creates significant ambiguity. The nesting is moderate but acceptable, with conditional checks in 'find' and 'fin' being understandable. Action granularity is mostly maintained. The reading flow is disrupted by having to mentally track what each numbered variation does, which is especially problematic for methods like 'get2' vs 'get3' or 'list2' vs 'list3'.
Run 2
The code is highly obfuscated with meaningless, non-descriptive method and variable names like 'get2', 'set3', 'ite4', 'coo11', 'dom6', and 'pat5'. This completely obscures intent and violates basic readability principles. While the code structure is linear and nesting is moderate, the naming destroys clarity of intent. The method 'set3' does additional string processing and calls 'set_cookie', making it misleading. Action granularity varies; some methods have dense comprehensions while others are verbose loops. The reading flow is unnatural because readers must constantly decode abbreviated or numbered identifiers. Docstrings attempt to explain behavior, but they cannot compensate for the cryptic names. The code appears to be an intentionally degraded version of a readable class, with suffixes and generic imports adding noise.
Run 3
The code is significantly unreadable due to ambiguous, non-descriptive method names like get2, set2, ite, fin, and upd, which obscure intent. Naming conventions are inconsistent and heavily truncated, making it difficult to understand functionality. The structure follows a class-based organization but methods are arranged without logical grouping. Nesting is moderate but readability suffers due to defensive checks and multiple conditions. Some methods contain verbose comments while others lack clarity. The code is longer than necessary, with redundant loops and repeated patterns that could be refactored. Action granularity is acceptable, but the reading flow is disrupted by cryptic names and abbreviations. Overall, the code meets functional requirements but fails readability standards, as it does not communicate purpose clearly to a reader unfamiliar with the codebase.
Run 1
1. Code Structure: Methods are logically grouped within a cohesive cookie-jar class, but inconsistent naming obscures the API organization. 2. Nesting: Most methods are shallow; fin and find contain unnecessarily deep conditional chains. 3. Clarity of intent: Docstrings and type annotations help, but cryptic names such as ite3, get4, coo11, and to hinder understanding. Documentation references original method and parameter names rather than the actual identifiers, creating confusion. 4. Code length: Individual methods are generally concise, though repetitive iteration helpers and lengthy, sometimes mismatched docstrings increase reading effort. 5. Action granularity: Almost every line performs one action; the assignment expression in set3 adds modest complexity. 6. Reading flow: Consistent formatting and method separation support scanning, but numbered identifiers, misplaced threading import, and discrepancies between documented and implemented names disrupt natural reading.
Run 2
Code Structure: Methods are logically separated within a cohesive class, but inconsistent naming and import organization weaken structure. Nesting: Most methods are shallow, while fin and find contain unnecessarily deep conditional chains. Clarity of intent: Docstrings and type annotations explain cookie operations, but cryptic, numbered identifiers such as ite3, get4, and coo11 obscure meaning. Documentation often references original method names rather than the actual names, increasing confusion. Code length: Individual methods are generally concise, though repetitive wrappers and extensive boilerplate documentation make the class lengthy. Action granularity: Almost every line performs one clear action; the assignment expression in set3 adds minor complexity. Reading flow: Consistent formatting and related method grouping help, but arbitrary naming, mismatched documentation, and calls such as new.update versus the defined upd force readers to reconcile inconsistencies.
Run 3
1. Code Structure: Methods are logically separated within a cohesive cookie-jar class, though imports are poorly grouped. 2. Nesting: Most methods are shallow, but fin and find contain several nested conditionals that complicate scanning. 3. Clarity of intent: Docstrings and type annotations help substantially, but cryptic, numbered names such as ite3, get4, coo11, and nam8 obscure purpose. Documentation references original method and parameter names rather than actual ones, further confusing the interface. The multiple method's implementation also conflicts with its stated intent. 4. Code length: Individual implementations are generally concise, but repetitive wrappers and lengthy boilerplate documentation inflate the class. 5. Action granularity: Statements usually perform one action per line; the assignment expression in set3 is a minor exception. 6. Reading flow: Consistent formatting and method boundaries support navigation, but inconsistent naming and mismatched documentation force frequent cross-referencing.