Sample
pyint-cac60587cee2-I04
Replace names with deterministic minifier-style shortest identifiers
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.988 | 0–1; higher is more readable |
| Dorn | 0.276 | 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 | 7 | 0–20; mean of three runs |
| GPT-6.1 Sol | 13.67 | 0–20; mean of three runs |
| BTTF | 0.606 | 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. | 2222.559 | −73.344 |
| 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.47 | −6.705 |
Intercept 8.87 + feature contributions = 4.421 (log-odds).
Score = sigmoid(4.421) = 0.988.
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. | 189 | +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.024 | +0.704 |
| 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.963 | +0.236 |
Intercept 0.07 + feature contributions = -0.963 (log-odds).
Score = sigmoid(-0.963) = 0.276.
| Score | 0.77 |
|---|
| Score | 56 |
|---|
Run 1
The code has good documentation and logical organization, but suffers from severe readability issues in critical areas. The ClassProps.__init__ method uses meaningless parameter names (b through q) that force readers to cross-reference the __slots__ tuple and docstring to understand arguments. This destroys clarity of intent and disrupts reading flow. The method is also unnecessarily long with repetitive attribute assignments, violating action granularity and conciseness. While the overall structure is reasonable with clear docstrings and enums, the core constructor implementation reads like obfuscated code. The code mixes excellent documentation practices with poor naming conventions, creating a significant disconnect between the public API documentation and implementation. The flat structure and reasonable line lengths help, but cannot compensate for the opaque parameter naming in the main method.
Run 2
The code has clear structure with logical imports, nested enums, and a well-documented class. However, the __init__ method is severely problematic: parameters named 'b' through 'q' are meaningless and map to 16 positional arguments without any type hints or defaults. This makes the code nearly impossible to use correctly. The @property 'a' is also cryptically named. While the docstrings are excellent and the ClassProps structure is logical, the core implementation destroys readability. The slot ordering comment helps, but the constructor signature requires guessing/intuition. Action granularity is fine—one assignment per line—but reading flow breaks completely at the parameter list. The class-level nesting (ClassProps > Hashability, KeywordOnly) is acceptable depth. Overall, the public interface is well-documented, but the implementation hides all intent behind single-letter names that don't align with the documented attributes, forcing readers to cross-reference slot ordering manually.
Run 3
The code is largely unreadable due to its constructor using meaningless parameter names (b through q) with no type hints or defaults, hiding intent completely and making it impossible to understand what arguments to pass. The class-level documentation is excellent and the enums are well-organized, which shows clarity of intent at a high level, but the actual implementation completely undermines it. The '__init__' method is unnecessarily long, with one assignment per line but repeated in a monotonous pattern, violating conciseness and action granularity. The docstrings for enums and slots are good, but the parameter naming breaks reading flow and maintainability. Nesting is flat, and structure is logical at the module level, but the core parameter design is a major readability failure.
Run 1
Code Structure: Logically organized into a documented class, related nested enums, slots, initialization, and a property. Nesting: Shallow and appropriate; nested enums do not complicate control flow. Clarity of intent: Descriptive attributes and extensive documentation explain the data model, but constructor parameters b through q and property name a obscure meaning and make positional mapping difficult to follow. Code length: Verbose documentation and the expanded constructor signature lengthen a relatively simple implementation; the assignments themselves are justified. Action granularity: Each assignment performs one action per line, and the property expression is clearly formatted. Reading flow: The class proceeds naturally from documentation to definitions and methods, but readers must repeatedly map anonymous constructor parameters to named attributes. Overall, readable organization is undermined primarily by poor parameter and property naming.
Run 2
Code Structure: Logically organized into a documented class, related enums, slots, initialization, and a property. Nesting: Shallow and easy to follow; nested enums naturally belong to the class. Clarity of intent: Descriptive attributes and extensive documentation explain the data model, but constructor parameters b–q and property name a obscure intent and require cross-referencing assignments. Code length: Documentation is useful but dominates the snippet; the long constructor and repetitive assignments add scanning overhead. Action granularity: Each assignment performs one action per line, and enum definitions are clearly separated. Reading flow: Generally natural, progressing from documentation to definitions and implementation, but opaque parameter names disrupt comprehension. Numerous imports unused within this snippet also introduce visual noise.
Run 3
Code Structure: The class is logically organized into documentation, related enums, slots, initialization, and a property. Nesting: Shallow and easy to follow; nested enums are appropriate. Clarity of intent: Descriptive attribute names and thorough documentation explain the data model, but constructor parameters b through q and property a obscure their purposes and require manual mapping. Code length: Extensive documentation is useful, though the long constructor signature and repetitive assignments make a simple data container verbose. Action granularity: Each assignment and enum declaration performs one clear action per line. Reading flow: Consistent formatting and matching slot/assignment order support sequential reading, but opaque parameter names interrupt comprehension. Overall, the structure is readable, with naming deficiencies being the main weakness.