Sample
pyint-457d101c5ee6-I08
Select one of ten high-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.1 | 0–1; higher is more readable |
| Mi | 0.583 | 0–1; higher is more readable |
| LLOC | 78 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 15.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs |
| BTTF | 0.409 | 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. | 5704.47 | −188.248 |
| Source linesThe number of non-empty source lines. | 276 | +110.4 |
| 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.378 | −6.567 |
Intercept 8.87 + feature contributions = -75.544 (log-odds).
Score = sigmoid(-75.544) = 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. | 277 | −8.771 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 202 | +6.25 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 202 | −4.214 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 275.946 | +3.447 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 90.982 | +0.664 |
| 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.96 | −0.187 |
Intercept 0.07 + feature contributions = -2.201 (log-odds).
Score = sigmoid(-2.201) = 0.1.
| Score | 0.583 |
|---|
| Score | 78 |
|---|
Run 1
The code demonstrates moderate readability. The class structure with `__slots__`, clear docstrings, and consistent method grouping shows good organization. However, several issues reduce its score: (1) The `__init__` method takes 20 parameters, making it unnecessarily long and difficult to follow. (2) There is an unexplained, dead-code block with 'first_score', 'second_score', and 'higher_score' variables that serves no purpose and disrupts reading flow. (3) The `first_score`/`second_score` block violates action granularity and clarity of intent - it appears to be leftover debugging code. (4) Multiple operations are packed into single lines (e.g., tuple unpacking in `_determine_attrib_eq_order` call). (5) The conditional expressions for 'alias_is_default' and 'metadata' are complex and reduce readability. (6) Some parameter names are cryptic ('cmp', 'ca'). While the docstrings are helpful and the general class structure is logical, the tangled parameter handling, dead code, and compact expressions make this code harder to read than necessary.
Run 2
The code is highly readable with clear structure and logical organization. The Attribute class is well-documented with comprehensive docstrings explaining its purpose and usage. Methods are concise and follow single-responsibility principles. The code maintains flat nesting with no deep conditional chains, and each line typically performs one action. Intent is clear throughout - from the descriptive method names like from_counting_attr to the explicit _setattrs helper. The slot definitions and initialization are straightforward. Minor issues include the confusing unused score comparison logic in __init__ and some manual __setattr__ workarounds, but these are well-commented. The code follows Python best practices with type hints, proper imports, and clear variable naming.
Run 3
The code demonstrates strong readability with clear structure, logical organization, and well-documented intent. The Attribute class has a clean __slots__ declaration, proper type hints on new methods, and excellent docstrings explaining purpose and parameters. Nesting is minimal throughout, with only shallow conditional blocks in evolve() and __setstate__(). Action granularity is good - each line typically performs one clear operation. The code length is appropriate given the complexity of the attribute system being implemented. However, there are a few minor concerns: some methods like evolve() and __setstate__() could benefit from slightly more explicit logic separation, and the pickle-related comments are brief. The unused 'cmp' parameter with an XXX comment is a minor code smell, though appropriately documented. Overall, the code follows Python best practices, maintains consistent naming conventions, and effectively balances the complexity of attribute handling with clear, maintainable structure.
Run 1
Code Structure: Methods logically separate initialization, copying, serialization, and attribute updates, but unrelated score-comparison code disrupts the constructor. Nesting: Mostly shallow, with manageable conditionals and one loop. Clarity of intent: Descriptive method names, extensive documentation, and explanatory comments help; descriptor manipulation, external helpers, and the long positional constructor call require extra interpretation. Code length: Documentation is substantial but useful; repetitive assignments and unused score calculations add bulk. Action granularity: Generally one action per line, with clearly formatted multiline expressions. Reading flow: Method organization is natural, but the large parameter list, positional argument mapping, and awkwardly wrapped compatibility expression slow reading.
Run 2
Code Structure: Methods logically separate initialization, copying, serialization, and immutable assignment, but unrelated score-comparison code disrupts the constructor. Nesting: Mostly shallow, with manageable conditionals and loops. Clarity of intent: Descriptive method names, documentation, and explanatory comments help, although internal helpers, descriptor manipulation, and a long positional constructor call require careful interpretation. Code length: Extensive documentation is useful, but repetitive attribute assignments, numerous parameters, and the unused higher_score calculation add bulk. Action granularity: Generally one action per line; tuple unpacking and conditional expressions introduce modest density without excessive compression. Reading flow: Consistent formatting and method boundaries support navigation, but awkwardly wrapped alias inference, repeated metadata conversion, and the irrelevant constructor block interrupt an otherwise coherent flow.
Run 3
Code Structure: Methods are logically grouped within a cohesive class, but the unrelated score comparison in __init__ distracts from initialization. Nesting: Mostly shallow, with manageable conditionals and loops; multiline conditional expressions add some complexity. Clarity of intent: Descriptive method names, documentation, and explanatory comments communicate purpose well. Internal helpers, descriptor-based assignment, and lengthy positional constructor calls require extra interpretation. Code length: Generally justified by functionality, although extensive documentation, repetitive assignments, and unused score logic reduce concision. Action granularity: Most lines perform one action, with clear assignment and mutation steps; tuple unpacking and compound expressions remain reasonably readable. Reading flow: Consistent formatting and method boundaries support navigation, but the large constructor signature, positional argument mapping, and awkwardly wrapped pickle compatibility expression interrupt the flow.