Sample
pyint-9f04ebe65e38-SRC
Unmodified source class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.002 | 0–1; higher is more readable |
| Dorn | 0.697 | 0–1; higher is more readable |
| Mi | 0.535 | 0–1; higher is more readable |
| LLOC | 29 | 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.719 | 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. | 1056.775 | −34.874 |
| Source linesThe number of non-empty source lines. | 66 | +26.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.513 | −6.769 |
Intercept 8.87 + feature contributions = -6.372 (log-odds).
Score = sigmoid(-6.372) = 0.002.
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. | 67 | −1.336 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 46 | +0.854 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 46 | −0.635 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.039 | +0.566 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 65.833 | +0.51 |
| 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. | 77 | +0.404 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 74.612 | +0.399 |
Intercept 0.07 + feature contributions = 0.833 (log-odds).
Score = sigmoid(0.833) = 0.697.
| Score | 0.535 |
|---|
| Score | 29 |
|---|
Run 1
The code is well-structured with clear imports, docstrings, and class organization. The Factory class has a single responsibility and uses __slots__ appropriately. Nested logic is minimal, with only a single loop in __setstate__ using zip with strict=True for safety. Intent is clearly conveyed through descriptive naming and comprehensive docstrings explaining purpose, arguments, and version additions. Code length is concise without being terse; each method contains only essential logic. Action granularity is appropriate - each line performs one clear operation, like tuple unpacking in __getstate__ or the zip iteration in __setstate__. Reading flow is natural, moving from class documentation through constructor to serialization methods. Minor improvements could include type hints on method parameters and more explicit error handling in __getstate__ if attributes are missing, but overall the code is highly readable and maintainable.
Run 2
The code is generally clear and well-organized. It uses straightforward imports, a simple class with `__slots__`, and concise methods. The `Factory` class has a clear purpose, and the docstrings explain its behavior and parameters. The pickle support methods are brief and logical. Minor deductions: the `zip` call with `strict=True` assumes Python 3.10+, which may not be obvious to all readers; the class name is generic but acceptable in context; and a few lines (like `return tuple(getattr(self, name) for name in self.__slots__)`) pack multiple logical actions, slightly reducing action granularity. Overall, the code is readable and maintainable.
Run 3
The code is well-structured with clear imports, a focused single class, and descriptive docstrings. Nesting is flat, intent is clear, and action granularity is appropriate. The Factory class has a single responsibility, and methods are concise, though __getstate__ and __setstate__ could be slightly simplified. Overall readable and maintainable.
Run 1
Code Structure: The class is logically organized into documentation, slots, initialization, and serialization methods, although the extensive imports appear unused in this snippet. Nesting: Methods are flat, with only a simple loop in __setstate__. Clarity of intent: Descriptive names and a detailed class docstring clearly explain the factory's purpose; the serialization docstrings are less precise. Code length: The implementation is concise, though the import block and documentation dominate this small excerpt. Action granularity: Each statement performs one clear action, with a straightforward generator expression for collecting state. Reading flow: The progression from initialization to saving and restoring state is natural. Minor spacing improvements between imports and the class would further improve readability.
Run 2
Code Structure: Imports and a single, cohesive class are logically organized, although many imports are unused in this excerpt. Nesting: Methods are flat, with only one simple loop. Clarity of intent: Descriptive names and a detailed class docstring clearly explain the factory and takes_self behavior; serialization docstrings are less specific. Code length: The implementation is concise, though the extensive imports and documentation outweigh the small amount of executable code. Action granularity: Statements generally perform one action per line; the generator expression remains straightforward. Reading flow: The progression from documentation to slots, initialization, and serialization is natural. Additional blank lines between import groups and before the class would improve visual separation.
Run 3
Code Structure: The class is logically organized into initialization and serialization methods, although many imports are unused in this snippet. Nesting: Methods are flat, with only a simple loop in __setstate__. Clarity of intent: Descriptive names and a detailed class docstring clearly explain the factory's purpose; serialization docstrings are less specific. Code length: The implementation is concise, but the extensive imports and documentation add overhead relative to its size. Action granularity: Each statement performs a single clear action. Reading flow: The progression from class documentation to initialization and state handling is natural, though the import-heavy opening and limited spacing between sections slightly reduce readability.