Sample
pyint-b4a92a1c7ec0-I01
Remove comments and docstrings
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.758 | 0–1; higher is more readable |
| Mi | 0.412 | 0–1; higher is more readable |
| LLOC | 17 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 15 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17.33 | 0–20; mean of three runs |
| BTTF | 0.638 | 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. | 585.498 | −19.321 |
| Source linesThe number of non-empty source lines. | 20 | +8 |
| 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.562 | −6.842 |
Intercept 8.87 + feature contributions = -9.294 (log-odds).
Score = sigmoid(-9.294) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| 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. | 63.952 | +0.956 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.055 | +0.404 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 21 | +0.293 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 19.923 | −0.131 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 20 | −0.045 |
Intercept 0.07 + feature contributions = 1.14 (log-odds).
Score = sigmoid(1.14) = 0.758.
| Score | 0.412 |
|---|
| Score | 17 |
|---|
Run 1
The code is generally readable and well-structured. It uses clear imports, type hints, and a logical class extension pattern. The __init__ method is flat with a single conditional check and delegates initialization cleanly. However, there are minor issues: a blank line after the class definition line is unnecessary, the 'app: App' type annotation references an undefined 'App' class in this code fragment, and the intent of 'create_global_jinja_loader()' is not immediately clear without surrounding context. Additionally, the conditional override of the loader before calling the parent constructor could be slightly more explicit. Overall, the code is concise, has good granularity, and follows a natural reading flow, but would benefit from minor cleanup and a defined type reference.
Run 2
The code is generally readable with clear imports and a straightforward class definition. The constructor logic is simple and the intent is understandable: set up a Jinja2 environment with a default loader if none is provided. The unused imports (BaseLoader, Template, TemplateNotFound, app_ctx, stream_with_context, before_render_template, template_rendered) reduce clarity by suggesting dependencies that are not used. The blank line after the class declaration is a minor style issue. The method has one action per line and is not deeply nested, which aids comprehension. However, the presence of 'App' in a type hint without a visible import or definition creates ambiguity about its origin, slightly reducing clarity of intent.
Run 3
The code is generally structured but has readability gaps. The class definition with an empty line after it creates unnecessary visual separation. The __init__ method is clear but moderately nested - the 'if' block containing a method call is a single-level nesting, which is acceptable. The intent is mostly clear through naming (app, Environment, loader) though 'app: App' lacks an import for the App type. Code length is concise. Each action is on its own line, maintaining good granularity. Reading flow is slightly disrupted by the empty line after class definition and potential App type reference without import. The code follows standard patterns for extending Jinja2 environments. Score reflects solid but not exceptional readability due to minor structural choices and missing type import that could confuse readers.
Run 1
Code Structure: Imports and the environment subclass are logically organized, although several imports are unused in this snippet. Nesting: A single conditional keeps nesting shallow. Clarity of intent: The constructor clearly supplies a default template loader, initializes the base environment, and stores the application; however, App is not defined or imported in the shown code. Code length: The implementation is concise, with only minor excess whitespace and unused imports. Action granularity: Each statement performs one distinct action. Reading flow: Initialization follows a natural sequence, though the explicit base-class initializer is slightly less idiomatic than super().__init__.
Run 2
Code Structure: Imports followed by a focused subclass provide logical organization, although several imports are unused in this snippet. Nesting: A single conditional keeps nesting shallow. Clarity of intent: The initializer clearly supplies a default template loader and stores the application, but the App annotation has no visible import or definition. Code length: The implementation is concise; unused imports and excess blank lines add minor clutter. Action granularity: Each statement performs one clear action. Reading flow: Initialization proceeds naturally from configuring the loader to initializing the base environment and saving the app reference.
Run 3
Code Structure: Imports precede a clearly defined subclass and constructor, although several imports are unused in this snippet. Nesting: Only one shallow conditional makes the code easy to follow. Clarity of intent: The constructor clearly supplies a default Jinja loader, initializes the base environment, and stores the application; however, the App annotation is not defined or imported in the snippet. Code length: The implementation is concise, with minor clutter from imports and excess blank space. Action granularity: Each statement performs one clear action. Reading flow: Execution proceeds naturally from loader configuration to base initialization and application storage. Using super().__init__ would make the inheritance pattern more idiomatic.