Sample
pyint-5473842403c0-SRC
Unmodified source class
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 | 16 | 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 well-structured and organized, with clear class boundaries and logical method ordering. Imports are comprehensive and properly segmented. Documentation is thorough, though verbose, which aids clarity but increases length. Nesting is minimal - only a few conditional blocks exist, mostly flat with clear early returns. Intent is explicit throughout, with descriptive variable names and comments explaining non-obvious operations. However, some methods are long (particularly __init__) with repetitive bound_setattr calls, and the number of parameters creates complexity. Action granularity is generally good - one operation per line in most places - but the __init__ method's repetitive assignments could be refactored. Reading flow is natural, following a logical progression from initialization to methods. The code is slightly verbose in documentation but maintains high readability overall. Some complexity exists around attr alias handling and evolution logic that requires careful reading.
Run 2
The code is generally well-structured and readable. It uses clear class-level docstrings, logical slot ordering, and concise helper methods. The __init__ method is long but flat, with one action per line and explicit comments explaining non-obvious logic. Methods like evolve and __setstate__ isolate complex behavior cleanly. Minor deductions come from dense parameter lists and a few compact conditional expressions that slightly reduce clarity, but overall the code is maintainable and intent is clear.
Run 3
The code is generally well-structured and readable, with clear class documentation, logical organization, and consistent naming. The Attribute class has a clear purpose, and methods like evolve, __getstate__, and _setattrs are reasonably concise. However, there are readability challenges: the __init__ method has a large number of parameters (some with unclear or deprecated names like 'cmp'), and it performs many sequential bound_setattr calls that could be grouped. The from_counting_attr method contains moderate nesting and conditional logic. Comments are helpful but sparse in places. Overall, the code is above average in clarity but slightly verbose in spots.
Run 1
Code Structure: Methods are logically organized around initialization, copying, serialization, and internal updates, with helpful documentation. Nesting: Mostly flat, with only shallow conditionals and loops. Clarity of intent: Descriptive method names and comments explain immutability, metadata handling, and compatibility behavior; descriptor manipulation, external helpers, and the long positional constructor call require extra effort to understand. Code length: Generally justified, though extensive documentation and repetitive attribute assignments make the class lengthy. Action granularity: Almost every statement performs one action, with clear separation of assignments and checks. Reading flow: Consistent formatting and focused methods support natural reading, but multiline conditional expressions, slot-order dependence, and positional argument mapping interrupt the flow.
Run 2
Code Structure: Logically organized around a single class, with separate methods for construction, copying, serialization, and internal updates. Nesting: Mostly flat, with only shallow loops and conditionals; multiline conditional expressions introduce some complexity. Clarity of intent: Descriptive method names, detailed documentation, and explanatory comments clarify behavior, though low-level descriptor usage, external helpers, and the unused cmp parameter require additional context. Code length: Generally justified by functionality, but extensive documentation, repetitive field assignments, and the large constructor increase reading effort. Action granularity: Consistently performs one action per statement, with no compressed multi-action lines. Reading flow: Methods follow a sensible progression and formatting is consistent, but the long positional constructor call, slot-order dependency, and awkwardly wrapped compatibility expression interrupt otherwise natural reading.
Run 3
Code Structure: Methods are logically separated into initialization, construction, copying, serialization, and internal mutation, with useful documentation. Nesting: Mostly flat control flow; limited conditionals and loops keep complexity manageable. Clarity of intent: Descriptive method names, comments, and docstrings explain immutability and compatibility behavior, but descriptor binding, external helpers, and the long positional constructor call require extra effort to understand. Code length: Repetitive field assignments and extensive documentation increase length, though much of this supports explicitness and public API documentation. Action granularity: Statements generally perform one action each; tuple unpacking and conditional expressions remain reasonably focused. Reading flow: Consistent formatting and method grouping support natural progression, but multiline expressions in state restoration, order-dependent slots, and numerous constructor parameters interrupt scanning. Overall, readable and well organized, with some complexity from low-level implementation details and backward compatibility.