Sample
pyint-1b0e8ac63e7a-I10
Deterministically remove some optional blank lines and bracketed line breaks
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.002 | 0–1; higher is more readable |
| Dorn | 0.799 | 0–1; higher is more readable |
| Mi | 0.48 | 0–1; higher is more readable |
| LLOC | 11 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 18.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18.33 | 0–20; mean of three runs |
| BTTF | 0.752 | 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. | 408.424 | −13.478 |
| 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.62 | −6.93 |
| Source linesThe number of non-empty source lines. | 13 | +5.2 |
Intercept 8.87 + feature contributions = -6.338 (log-odds).
Score = sigmoid(-6.338) = 0.002.
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. | 55.857 | +1.299 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 14 | +0.541 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.057 | +0.393 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 13 | −0.287 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 12.912 | −0.229 |
Intercept 0.07 + feature contributions = 1.379 (log-odds).
Score = sigmoid(1.379) = 0.799.
| Score | 0.48 |
|---|
| Score | 11 |
|---|
Run 1
The code is highly readable with a clear, logical structure. Imports are grouped and ordered conventionally, the class definition is clean and properly extends AppConfig, and the single method `ready` has a clear intent of connecting a signal. Nesting is minimal, with only one level of class-method indentation. Action granularity is appropriate — one action per statement. The reading flow is natural: config metadata first, then behavior. The only minor deduction is that the imported `base`, `get_level_tags`, and `SimpleLazyObject` are unused, and the function `update_level_tags` is not defined in this snippet; these could cause ambiguity about intent. Overall, concise and well-structured code.
Run 2
The code is concise, well-structured, and follows Django conventions. Imports are organized logically, the class has clear attributes, and the ready() method performs a single, clearly named action (connecting a signal). There is no unnecessary nesting, and the reading flow is natural. Minor deductions for the unused 'base' import and 'get_level_tags' import, which slightly reduce clarity of intent and add unnecessary length.
Run 3
The code is well-structured and follows Django conventions, making it highly readable. It is concise, with a clear class definition and a single method that connects a signal. The nesting is flat, and each import is on a separate line, adhering to PEP 8. The action granularity is appropriate—one clear action per line. The use of `verbose_name` and `ready` clearly signals intent. Minor deductions: `get_level_tags` and `update_level_tags` are imported but not defined in this snippet, which may cause slight ambiguity without context, but this is not a fault of the code itself. Overall, it is almost ideal for this kind of configuration file.
Run 1
Code Structure: Imports and the AppConfig subclass are logically organized. Nesting: Minimal, with only a class and a short method. Clarity of intent: Descriptive names make the configuration and signal registration clear, though update_level_tags is not defined or imported in the snippet. Code length: Very concise, but several unused imports add minor clutter. Action granularity: Each statement performs one action. Reading flow: Natural progression from imports to configuration attributes to startup behavior; an additional blank line before the class would improve formatting.
Run 2
Code Structure: Imports and a focused AppConfig class are logically organized, though several imports are unused in this snippet. Nesting: Minimal, with only a class and its short method. Clarity of intent: The configuration metadata is clear, and ready() visibly registers a settings-change handler; however, update_level_tags is neither defined nor imported here, obscuring its origin. Code length: Concise, with no unnecessary implementation. Action granularity: Each assignment and the signal connection occupy separate lines. Reading flow: Natural progression from imports to configuration to initialization, though an additional blank line before the class would improve conventional formatting.
Run 3
Code Structure: Imports and application configuration are logically organized, though several imports are unused in the snippet. Nesting: Minimal, with only a class and its method. Clarity of intent: The configuration metadata and signal registration are clear, but update_level_tags is neither defined nor imported, making the callback's origin unclear. Code length: Short and focused, aside from unused imports. Action granularity: Each statement performs one action. Reading flow: Natural progression from imports to metadata to initialization, though an additional blank line before the class would improve formatting.