Sample
pyint-7c2bb026b379-I05
Rewrite eligible decimal integer literals in hexadecimal notation
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 highly readable due to its clear structure, minimal nesting, concise length, and natural flow. It imports only necessary modules, defines a simple configuration class with a single responsibility, and connects a single signal in one action per line. The intent is unambiguous, and the line length/formatting adheres to common Python style. The only minor deduction is the unused 'base' import, which slightly reduces clarity.
Run 3
The code is concise and logically structured, with clear imports and a straightforward class definition. The class inherits from AppConfig, has descriptive attributes, and a ready() method whose purpose is evident. There is minimal nesting and each line generally performs a single action, preserving a natural reading flow. The only slight ambiguity comes from the signal connection in ready(): while it is concise, connecting setting_changed to update_level_tags without nearby context or a comment may leave a reader wondering about the exact behavior. Nonetheless, the code is very readable overall.
Run 1
Code Structure: Imports and app configuration are logically organized. Nesting: Minimal nesting, limited to a class and its method. Clarity of intent: Descriptive names clearly communicate message-app configuration and signal registration, though update_level_tags is not defined or imported in the snippet. Code length: Very concise, but several unused imports add clutter. Action granularity: Each statement performs a single action. Reading flow: Natural top-to-bottom progression from imports to configuration to initialization; an additional blank line before the class would improve visual separation.
Run 2
Code Structure: Imports and a single AppConfig subclass are logically organized, though several unused imports add clutter. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: Descriptive class names and attributes clearly identify the messages app configuration; ready() registers a settings-change handler, but update_level_tags is not defined or imported in the snippet. Code length: Very concise, with little unnecessary code beyond the unused imports. Action granularity: Each line contains one declaration or action. Reading flow: Natural progression from imports to configuration attributes to initialization behavior, although an additional blank line before the class would improve conventional formatting.
Run 3
Code Structure: Imports and a single configuration class are logically organized, though several imports are unused in this snippet. Nesting: Minimal, with only one method inside the class. Clarity of intent: The class metadata and signal connection clearly express application initialization, but update_level_tags is neither defined nor imported, leaving the callback unclear. Code length: Very concise, with no unnecessary logic. Action granularity: Each statement performs one action. Reading flow: Natural progression from imports to configuration and initialization; an additional blank line before the class would improve conventional Python formatting.