Sample
pyint-203033a416af-SRC
Unmodified source class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.002 | 0–1; higher is more readable |
| Dorn | 0.459 | 0–1; higher is more readable |
| Mi | 0.464 | 0–1; higher is more readable |
| LLOC | 35 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs |
| BTTF | 0.653 | 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. | 1777.581 | −58.66 |
| Source linesThe number of non-empty source lines. | 126 | +50.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.517 | −6.775 |
Intercept 8.87 + feature contributions = -6.165 (log-odds).
Score = sigmoid(-6.165) = 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. | 127 | −3.46 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 125.856 | +1.349 |
| 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. | 110 | −0.994 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 109.976 | +0.97 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 46 | +0.854 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.03 | +0.649 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = -0.164 (log-odds).
Score = sigmoid(-0.164) = 0.459.
| Score | 0.464 |
|---|
| Score | 35 |
|---|
Run 1
The code is highly readable due to its clear class-based structure, comprehensive docstrings, and logical organization. The View class is well-documented with examples and version notes, making intent explicit. Function definitions are straightforward, and type hints improve clarity. Nesting is minimal—only one level in the as_view method's conditional blocks. The code is moderately concise, with some verbose type ignores and long lines that slightly reduce readability. Action granularity is generally good, though a few lines combine multiple operations (e.g., function calls with type ignores). Overall reading flow is natural, progressing logically from class attributes to methods. Minor deductions for occasional line length and type-ignore clutter.
Run 2
The code is well-structured and readable. It has clear class-level attributes with descriptive comments, logical grouping of methods, and a single public method with a docstring explaining its purpose. The as_view method is flat with minimal nesting, and actions are mostly one per line. The main readability drawback is the inline type-ignore comments, which slightly break flow, and the repeated view-function setup at the end could be more consolidated. Overall, intent is clear and the reading flow is natural, though a few long lines and type annotations add minor noise.
Run 3
The code demonstrates readable, well-structured Python. It is flat with minimal nesting, uses clear class-level attributes, and has descriptive docstrings and inline comments. The conditional branch in 'as_view' is logically separated, though the repeated 'view' function definitions add some length. Type hints and comments aid clarity. Some lines combine multiple actions (e.g., assigning multiple metadata attributes in a row), but overall the flow is natural and intent is clear. Concise and maintainable, with only minor verbosity in comments and repeated view definitions.
Run 1
Code Structure: Clearly organized into class configuration, an overridable dispatch method, and a view-function factory. Nesting: Shallow overall, although conditional inner functions and the decorator loop add modest complexity. Clarity of intent: Descriptive names, type annotations, and thorough documentation explain behavior and lifecycle choices; dynamic function attributes and type-ignore comments require extra attention. Code length: Implementation is concise, but extensive documentation and repeated function metadata assignments slightly slow scanning. Action granularity: Each statement generally performs one action, with no compressed multi-statement lines. Reading flow: Progresses naturally from configuration to dispatch, instance creation, decoration, and metadata setup. The two lifecycle branches duplicate the dispatch call, but their explicit separation makes the distinction easy to understand.
Run 2
Code Structure: Class configuration, dispatch behavior, and view creation are logically separated. Nesting: Shallow conditionals and a decorator loop keep complexity manageable, although nested view functions require some context tracking. Clarity of intent: Descriptive names, type annotations, and thorough documentation explain lifecycle behavior and metadata assignment; dynamic function attributes and type-ignore comments add minor friction. Code length: Executable code is concise, but extensive documentation and repeated dispatch and metadata statements increase reading length. Action granularity: Statements generally perform one action per line, with no compressed multi-statement lines. Reading flow: The progression from configuration to dispatch to factory logic is natural, though closure behavior, decorator application, and later attribute attachment require careful reading.
Run 3
Code Structure: Class configuration, dispatch behavior, and view-function creation are logically separated. Nesting: Mostly shallow, with modest nesting for conditional function definitions and decorator application. Clarity of intent: Descriptive names, type annotations, and thorough documentation explain lifecycle behavior and metadata; dynamic function attributes and closure-based instantiation require extra attention. Code length: Implementation is concise, although extensive documentation and repeated dispatch calls slightly increase reading effort. Action granularity: Statements generally perform one action per line; chained ensure_sync invocation is somewhat dense. Reading flow: Progresses naturally from configuration to dispatch and registration, but duplicate nested view definitions, long type-ignore comments, and repeated metadata assignments mildly interrupt the flow.