Sample
pyint-1c145a4ace99-SRC
Unmodified source class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.998 | 0–1; higher is more readable |
| Dorn | 0.28 | 0–1; higher is more readable |
| Mi | 0.77 | 0–1; higher is more readable |
| LLOC | 56 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs |
| BTTF | 0.64 | 0–1; higher is more readable |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Source linesThe number of non-empty source lines. | 189 | +75.6 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 2161.997 | −71.346 |
| 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.501 | −6.752 |
Intercept 8.87 + feature contributions = 6.372 (log-odds).
Score = sigmoid(6.372) = 0.998.
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. | 190 | −5.691 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 114 | +3.206 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 188.988 | +2.232 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 114 | −2.195 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.023 | +0.721 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 79.3 | +0.475 |
| 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. | 80.911 | +0.238 |
Intercept 0.07 + feature contributions = -0.944 (log-odds).
Score = sigmoid(-0.944) = 0.28.
| Score | 0.77 |
|---|
| Score | 56 |
|---|
Run 1
The code is highly readable with clear structure and intent. The ClassProps class uses __slots__ and has a straightforward __init__ that maps parameters to attributes one per line. The nested enums (Hashability, KeywordOnly) are logically grouped and well-documented. Each enum value has a docstring explaining its purpose. The docstring for ClassProps is comprehensive, documenting all attributes with types and descriptions. The is_hashable property is concise and readable. Import organization is clean, using standard library, third-party, and local imports in separate blocks. Minor deductions: the __init__ method is somewhat long (16 parameters) but unavoidable given the class's purpose as a data container; the enum value assignments use string values rather than auto() which is stylistic but acceptable. Overall, the code demonstrates excellent organization, minimal nesting, clear intent, and natural reading flow.
Run 2
The code is highly readable with clear logical organization: imports are grouped logically, class hierarchy is well-structured, and documentation is comprehensive. The ClassProps class uses a clean flat structure with minimal nesting, and the nested enums (Hashability, KeywordOnly) are appropriately encapsulated. Intent is exceptionally clear through detailed docstrings and version annotations. While the __init__ method is somewhat verbose with 16 parameters, this is justified by the class's purpose and the parameters are clearly named and consistently assigned. Action granularity is excellent—one assignment per line in __init__ and one field per line in __slots__. The is_hashable property is concise and readable. The only minor drawbacks are the lengthy parameter list and the experimental feature warning, which slightly impact readability but are necessary for transparency. Overall, the code follows best practices for maintainable, well-documented Python.
Run 3
The code is well-structured and readable. Imports are organized, the class has a clear docstring explaining its purpose, and nested enums provide good organization for related constants. The __slots__ declaration includes a helpful noqa comment explaining why order matters. The __init__ method is lengthy but straightforward, with one assignment per line following the __slots__ order. The is_hashable property uses clear boolean logic. Minor deductions: the __init__ has 16 parameters making it somewhat unwieldy, though this is justified by the data structure's purpose; the property could be simplified with 'in' operator for enum comparison. Overall, the code is maintainable and follows consistent patterns, though the parameter count creates some cognitive load.
Run 1
1. Code Structure: Well organized into imports, a documented properties class, related enums, slots, initialization, and a derived property. 2. Nesting: Shallow and appropriate; nested enums group related concepts without complicating control flow. 3. Clarity of intent: Descriptive names and comprehensive documentation clearly explain the class and its fields. Missing constructor type annotations slightly reduce clarity. 4. Code length: Verbose documentation and repeated field declarations across slots, parameters, and assignments increase length, but most repetition serves a clear purpose. 5. Action granularity: Each assignment performs one action, and multiline declarations and expressions remain easy to scan. 6. Reading flow: Predictable ordering and consistent formatting support natural reading. Minor drawbacks include the dense import section and the large constructor parameter list.
Run 2
Code Structure: Imports, class documentation, nested enums, slots, initialization, and the property are logically organized. Nesting: Shallow and appropriate; nested enums group related concepts without introducing complex control flow. Clarity of intent: Descriptive names and comprehensive docstrings make the class's purpose and fields clear, though constructor type annotations would improve precision. Code length: Some verbosity comes from repeating field names across documentation, slots, parameters, and assignments; the lengthy documentation is useful rather than gratuitous. Action granularity: Each assignment performs one action, and enum declarations and property logic are cleanly separated. Reading flow: The progression from documented interface to implementation is natural, with consistent formatting. Minor drawbacks include the large constructor parameter list, repetitive boilerplate, and limited spacing between import groups.
Run 3
Code Structure: Logically organized into documentation, related enums, slots, initialization, and a derived property. Nesting: Shallow and appropriate; nested enums clearly belong to ClassProps. Clarity of intent: Descriptive names and comprehensive docstrings make the purpose and individual properties clear, although constructor type annotations would improve clarity. Code length: Mostly justified by documentation and explicit field definitions, but repeating fields across documentation, slots, parameters, and assignments adds verbosity. Action granularity: Each assignment performs one action per line, and the hashability expression is cleanly formatted. Reading flow: Natural progression from the class contract to implementation details; minor spacing limitations around imports and the class slightly reduce polish. Overall, the code is highly readable, with modest deductions for repetitive declarations and a lengthy constructor.