Sample
pyint-3139ee945c70-I10
Deterministically remove some optional blank lines and bracketed line breaks
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.452 | 0–1; higher is more readable |
| Mi | 0.365 | 0–1; higher is more readable |
| LLOC | 35 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 14.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.639 | 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. | 116 | +46.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.514 | −6.772 |
Intercept 8.87 + feature contributions = -10.162 (log-odds).
Score = sigmoid(-10.162) = 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. | 117 | −3.106 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 115.847 | +1.209 |
| 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. | 109.966 | −0.993 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 109.991 | +0.97 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.03 | +0.648 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 39 | +0.612 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = -0.191 (log-odds).
Score = sigmoid(-0.191) = 0.452.
| Score | 0.365 |
|---|
| Score | 35 |
|---|
Run 1
The code is generally structured and documented, but readability is hurt by inconsistent formatting, dense class-level docstrings, and some awkward line breaks. The positive aspects: clear class design, docstrings explaining intent, and mostly flat logic. The negatives: the `as_view` method contains nested function definitions and repeated `return current_app.ensure_sync(...)` lines, making it harder to scan. There are also misaligned line breaks (e.g., `view.view_class` and the long line inside `view`), and multiple type-ignore comments interrupt reading flow. The class-level comments are verbose and sometimes break the visual grouping of attributes. Overall, the code is understandable for experienced Flask developers, but it requires effort to parse due to formatting inconsistencies and multipurpose sections. Score: 13.
Run 2
The code is generally readable with clear structure and intent. The View class is well-documented, and the as_view method follows a logical flow. However, there are a few issues: inconsistent indentation in the first branch of the conditional, occasional dense lines with multiple operations (e.g., type ignores and returns), and slightly unclear separation between branches. The nesting is shallow, which is good. Action granularity is mostly one action per line, but some lines combine function calls and type comments. Overall, it is maintainable but could benefit from minor formatting consistency improvements.
Run 3
The code is generally readable but has issues. Class variables with docstrings are well organized, and the `as_view` method follows a logical flow. However, there are problems with action granularity and nesting. The `view` function definitions inside `as_view` create nested functions, and lines like `self = view.view_class(*class_args, **class_kwargs)` mix type ignores with awkward spacing. The `ensure_sync(self.dispatch_request)(**kwargs)` call chains multiple actions on one line, reducing clarity. Reading flow is adequate but interrupted by long comments and type annotations. The branching between `init_every_request` paths adds complexity, though not deeply nested. Overall, the code is functional and documented but lacks consistent formatting and would benefit from cleaner line breaks and reduced chained method calls.
Run 1
Code Structure: Well-organized class with configuration attributes, an abstract dispatch method, and a view factory. Nesting: Mostly shallow; nested closures and a decorator loop add manageable complexity. Clarity of intent: Descriptive names, type annotations, and thorough documentation explain request handling and instance lifetimes, although dynamic function attributes and type-ignore comments require extra attention. Code length: Implementation is reasonably concise, but extensive documentation and repeated metadata assignments increase reading length. Action granularity: Most lines perform one action; chained ensure_sync calls slightly compress multiple operations. Reading flow: Progresses naturally from configuration to behavior to factory construction, but inconsistent blank lines, awkward argument formatting, and long inline comments interrupt the flow.
Run 2
Code Structure: The class logically groups configuration, dispatch behavior, and view construction, although spacing between sections is inconsistent. Nesting: Conditional branches and nested view functions add moderate, justified complexity without excessive depth. Clarity of intent: Descriptive names, type annotations, and thorough documentation explain the purpose well; dynamic function attributes and type-ignore comments require extra attention. Code length: Implementation is reasonably concise, but extensive documentation and duplicated wrapper logic lengthen the reading experience. Action granularity: Statements generally perform one action per line, with clear individual metadata assignments. Reading flow: Execution proceeds naturally from instance creation to decoration and metadata assignment. Irregular formatting around constructor arguments, long return lines, and limited blank lines slightly disrupt readability.
Run 3
Code Structure: The class cleanly separates configuration, request dispatch, and view creation. Nesting: Mostly shallow, although conditional nested functions and a decorator loop add moderate complexity. Clarity of intent: Descriptive names, type annotations, and thorough documentation explain behavior well; dynamic function attributes and type-ignore comments require extra attention. Code length: Executable code is concise, but extensive documentation and repeated metadata assignments increase reading length. Action granularity: Statements generally perform one action per line, with no compressed multi-statement lines. Reading flow: Configuration progresses naturally into dispatch and factory logic, but inconsistent blank lines, awkward constructor formatting, and long return statements interrupt the flow.