Sample
pyint-0c85dcc24825-I11
Split eligible integer literals into pairs of short-named intermediate variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.105 | 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 | 15.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.445 | 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. | 5522.817 | −182.253 |
| 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.383 | −6.575 |
Intercept 8.87 + feature contributions = -71.958 (log-odds).
Score = sigmoid(-71.958) = 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.957 | +3.364 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 90.978 | +0.663 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.041 | +0.541 |
| 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. | 90.956 | −0.187 |
Intercept 0.07 + feature contributions = -2.143 (log-odds).
Score = sigmoid(-2.143) = 0.105.
| Score | 0.583 |
|---|
| Score | 73 |
|---|
Run 1
The code is moderately readable. It has clear structure with a well-documented class, logical method organization, and good use of slots/type hints. However, it loses points due to long methods with many steps (__init__, evolve), repetitive bound_setattr calls that add vertical length without clarity, and some magic/complex conditional logic (alias_is_default handling). Nesting is generally flat, and intent is mostly clear, but the alias/alias_is_default interactions are subtle and not self-explanatory. The class docstring is thorough but very long. Action granularity is mostly one-per-line, which aids readability, but some lines pack multiple operations. Overall, it reads like mature library code with historical baggage; readable for maintainers but not immediately accessible to newcomers.
Run 2
The code demonstrates strong readability for a complex library class. It maintains a clear logical structure with well-organized imports, comprehensive docstrings, and consistent naming conventions. The Attribute class uses __slots__ for clarity and has clear initialization logic with minimal nesting. Most operations are single-purpose and follow a natural flow. The docstrings are thorough and explain the class's purpose, attributes, and version history. Minor deductions: the __init__ method is somewhat lengthy with many parameters (though appropriate for the domain), and a few sections like the pickle-related methods (_getstate_/_setstate_) add complexity but remain well-commented. Overall, the code is well-structured and maintainable, earning a high readability score.
Run 3
The code is generally well-structured with clear class organization and comprehensive documentation. The Attribute class has a logical layout with slots, __init__, and methods in sensible order. The use of bound_setattr caching is thoughtful and explained. However, some issues reduce readability: the __init__ method has many parameters and multiple setattr calls that could be more concise, the from_counting_attr classmethod has many positional arguments making the call hard to follow, and there are some lengthy conditional expressions in evolve and __setstate__ that sacrifice clarity. The docstring is detailed but very long, which could obscure the core purpose. Nesting is mostly flat, which is good, but action granularity could be improved by consolidating the repetitive bound_setattr calls. Overall, the code is readable for experienced Python developers familiar with attrs but may be challenging for others due to the complexity of the domain logic and number of parameters.
Run 1
Code Structure: Methods are logically separated into initialization, conversion, copying, serialization, and internal updates. Nesting: Mostly flat, with shallow conditionals and one simple loop. Clarity of intent: Descriptive method names, extensive documentation, and explanatory comments clarify behavior; private helpers, descriptor manipulation, and the large positional constructor call require extra interpretation. Code length: Generally justified, but lengthy documentation, repetitive assignments, and duplicated metadata conversion add bulk. Action granularity: Most lines perform one action; tuple unpacking and conditional expressions remain manageable. Reading flow: Consistent formatting and coherent method ordering help navigation, though multiline expressions, slot-order dependencies, and backward-compatibility handling interrupt otherwise straightforward reading.
Run 2
Code Structure: Methods are logically separated by responsibility, with comprehensive documentation and useful compatibility comments. Nesting: Mostly flat control flow; limited conditionals and loops keep complexity manageable. Clarity of intent: Descriptive method names and comments explain immutability, copying, and serialization, but descriptor-based assignments, external helpers, and slot-order dependencies require background knowledge. Code length: Repeated field assignments and lengthy documentation increase size, though much is justified; the long constructor and positional factory call are harder to scan. Action granularity: Statements generally perform one action per line, with no compressed multi-statement code. Reading flow: Organization is consistent and natural, but multiline conditional expressions, awkward wrapping in backward-compatible deserialization, and the many positional arguments interrupt readability. Overall, well-organized library code with some readability costs from compatibility requirements and low-level implementation details.
Run 3
Code Structure: Methods are logically grouped around initialization, copying, immutability, and serialization, though metadata conversion is duplicated. Nesting: Mostly flat, with shallow conditionals; multiline conditional expressions add some complexity. Clarity of intent: Descriptive names, extensive documentation, and explanatory comments clarify behavior, but external private helpers, descriptor binding, and a long positional constructor call require careful interpretation. Code length: Generally justified by functionality, although lengthy documentation and repetitive assignments make scanning slower. Action granularity: Statements generally perform one action per line, with compact tuple unpacking and comprehensions remaining understandable. Reading flow: The progression from construction to transformation and persistence is natural, but slot-order coupling, numerous constructor parameters, and awkward line breaks in compatibility logic interrupt readability.