Sample
pyint-56e61b2a25f5-I02
Shorten method, parameter, and local names without collisions
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.101 | 0–1; higher is more readable |
| Mi | 0.583 | 0–1; higher is more readable |
| LLOC | 73 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 6.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 12 | 0–20; mean of three runs |
| BTTF | 0.403 | 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. | 5686.409 | −187.651 |
| Source linesThe number of non-empty source lines. | 270 | +108 |
| 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.396 | −6.593 |
Intercept 8.87 + feature contributions = -77.375 (log-odds).
Score = sigmoid(-77.375) = 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. | 271 | −8.559 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 196 | +6.042 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 196 | −4.077 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 269.978 | +3.364 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 91.978 | +0.68 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.044 | +0.518 |
| 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. | 91.945 | −0.229 |
Intercept 0.07 + feature contributions = -2.191 (log-odds).
Score = sigmoid(-2.191) = 0.101.
| Score | 0.583 |
|---|
| Score | 73 |
|---|
Run 1
The code is heavily obfuscated by cryptic variable names (nam3, def2, ca2, eq2, eq3, etc.) and abbreviated method names (evo, from2, set), which severely obscures intent. The class structure itself is logical and the docstrings are clear, but the actual implementation works against readability. The long __init__ parameter list and positional argument passing in from2 make it error-prone and difficult to follow. Nesting is mostly flat, and action granularity is reasonable, but the pervasive use of short, non-descriptive identifiers and unexplained comments (e.g., 'XXX: unused, remove') reduce clarity. Reading flow is interrupted by constant mental mapping of abbreviated names to meaning. The metadata bound() blocks are repeated, adding unnecessary length. Overall, it reads like deliberately minified or legacy code, despite being part of a well-known library.
Run 2
The code relies heavily on cryptic, abbreviated variable names (nam, def2, val, rep, cmp2, has, ini, inh, ca2, kw2, etc.) and parameters like eq2/eq3/ord that obfuscate their purpose. The class docstring is helpful, but the method signatures and logic are hard to follow. There is moderate nesting, and some actions are split across multiple lines, but the overall flow is fragmented. The use of bound() to bypass __setattr__ is non-obvious. Despite comments and docstrings, the ambiguous naming and terse parameters significantly reduce readability.
Run 3
This code is extremely unreadable due to pervasive use of cryptic, abbreviated variable names (nam, def2, val, rep, cmp2, has, ini, inh, met, typ, con, kw, eq2, eq3, ord, order2, on, ali, alias2, nam2, nam3, etc.). These abbreviations obscure the meaning and intent of parameters and variables, forcing readers to constantly refer back to documentation or context. The code structure is moderately organized with clear class and method boundaries, and docstrings help explain the Attribute class purpose. However, the heavy use of positional arguments with short names makes method signatures difficult to understand. Nesting is relatively flat, which is positive, but the unclear naming overwhelms this advantage. Action granularity is reasonable—most lines perform a single logical operation—but the multiple assignments on single lines (e.g., eq2, eq3, ord, order2 = ...) and condensed logic in expressions reduce clarity. Reading flow is disrupted by the need to decode abbreviated parameters. The code is concise but at the cost of transparency; it reads almost obfuscated. Comments like 'XXX: unused' reveal technical debt. Overall, the lack of descriptive naming is the dominant factor making this code unreadable despite otherwise acceptable structure and length.
Run 1
Code Structure: Methods logically separate initialization, copying, and serialization, but evo calls _setattrs while the provided helper is named set, disrupting coherence. Nesting: Mostly shallow, with manageable conditionals and loops. Clarity of intent: Documentation and comments explain the class well, but abbreviated, numbered names such as def2, eq3, ca2, and nam5 obscure meaning; long positional argument lists require careful cross-referencing. Code length: Extensive documentation is useful, although repetitive assignments and compatibility handling make the implementation verbose. Action granularity: Generally one action per line, with a few compact multi-value assignments and conditional expressions increasing cognitive load. Reading flow: Method ordering is natural, but awkward line breaks, inconsistent naming, and comments referencing names absent from signatures interrupt comprehension.
Run 2
Code Structure: The class is logically divided into initialization, copying, serialization, and mutation helpers, but evo calls _setattrs while the shown helper is named set, making the organization harder to follow. Nesting: Mostly shallow, with manageable conditionals and loops. Clarity of intent: Detailed documentation and comments explain the purpose, but abbreviated, numbered names such as def2, eq3, ca2, and nam5 obscure meaning; numerous positional constructor arguments further complicate interpretation. Code length: Some length is justified by documentation and explicit field initialization, although repetitive assignments and awkward wrapping add reading overhead. Action granularity: Generally strong, with one assignment or operation per statement. Reading flow: Methods follow a sensible sequence, but inconsistent naming, dense conditional expressions, and dependencies on helpers outside the snippet interrupt otherwise natural progression.
Run 3
Code Structure: Responsibilities are separated into methods, with useful documentation, but slot-order dependencies and inconsistent helper naming complicate understanding. Nesting: Mostly shallow, with straightforward conditionals and one simple loop. Clarity of intent: The class purpose is well documented, but abbreviated and numbered identifiers such as def2, ca2, and eq3 obscure parameter meanings. The call to _setattrs contrasts confusingly with the defined set method. Code length: Some repetition is justified by explicit field initialization, though lengthy documentation and awkward wrapping slow scanning. Action granularity: Most lines perform a single action; tuple unpacking and conditional expressions occasionally compress multiple decisions. Reading flow: Method organization is logical, but the long positional constructor call, indirect setattr usage, and densely formatted compatibility logic require frequent cross-referencing.