Sample
pyint-eda2917662d7-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.768 | 0–1; higher is more readable |
| Mi | 0.586 | 0–1; higher is more readable |
| LLOC | 27 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 13.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.576 | 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. | 896.111 | −29.572 |
| Source linesThe number of non-empty source lines. | 44 | +17.6 |
| 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.209 | −6.313 |
Intercept 8.87 + feature contributions = -9.415 (log-odds).
Score = sigmoid(-9.415) = 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. | 44 | −0.522 |
| 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. | 74.889 | +0.493 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 35 | +0.473 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.049 | +0.462 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 74.867 | +0.404 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 35 | −0.382 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 43.724 | +0.201 |
Intercept 0.07 + feature contributions = 1.2 (log-odds).
Score = sigmoid(1.2) = 0.768.
| Score | 0.586 |
|---|
| Score | 27 |
|---|
Run 1
The code is generally readable with clear class purpose and docstrings. However, it has some issues: missing blank lines between methods, an unneeded 'inspect' import in the __init__ method, unused imports at the top, and inconsistent formatting in the get_return_type method. The class name and method names are descriptive, and the logic is straightforward with flat nesting. The action granularity is reasonable, though some multi-line conditionals could be more concise. Overall, the code is understandable but would benefit from better formatting and import management.
Run 2
The code is generally readable but has some issues. The class structure is logical and docstrings are helpful, but the code fails to meet several criteria. The import of `inspect` is repeated in every method, which is unnecessary and disrupts flow. The `get_first_param_type` method uses a more complex approach than needed. There is an unused import (`sys`, `threading`) and type hints that are imported but not used. The nesting is minimal, but there are inconsistencies with spacing and line breaks. The `__slots__` usage is good, but the overall structure could be tightened. Action granularity is mostly appropriate, but some lines could be broken down further. The code lacks a consistent style (e.g., blank lines between methods).
Run 3
The code is moderately readable. Structure is logical with a clear class responsibility and separated methods, but imports inside methods and inconsistent spacing (class vs method spacing, multi-line condition in one method but not others) slightly hurt clarity. Nesting is low, which is good, and actions are generally one per line. However, repeated imports of 'inspect' inside each method and the presence of unused imports (sys, threading, typing._GenericAlias) add noise. Type hints are missing, which reduces clarity of intent. The docstrings are helpful, but the code could be more concise by centralizing the inspect import and using cleaner conditionals.
Run 1
Code Structure: A focused class logically separates signature extraction from parameter and return annotation retrieval, though missing blank lines reduce visual separation. Nesting: Shallow conditionals and a simple try/except keep complexity low. Clarity of intent: Descriptive method names and docstrings clearly explain the purpose; the abbreviated 'sig' attribute and parameter named 'callable' are minor weaknesses. Code length: Methods are concise, but unused module-level imports and repeated local inspect imports add clutter. Action granularity: Each statement performs a single clear action. Reading flow: Initialization followed by annotation accessors is natural, with straightforward early returns; inconsistent spacing and the unnecessarily expanded return-type condition slightly interrupt readability.
Run 2
Code Structure: The class logically groups signature extraction and annotation access, though inconsistent blank lines weaken separation. Nesting: Shallow conditionals and early returns keep control flow simple. Clarity of intent: Descriptive method names and docstrings make the purpose clear; 'sig' is abbreviated, and the parameter 'callable' shadows a built-in. Code length: Concise overall, but unused module-level imports and repeated local inspect imports add clutter. Action granularity: Each line generally performs one action, with no compressed statements. Reading flow: Initialization naturally precedes accessor methods, and exception handling is straightforward. Missing spacing between some methods and an unnecessarily spread-out return-annotation condition slightly interrupt the flow.
Run 3
Code Structure: A focused class cleanly separates signature extraction from parameter and return annotation retrieval, though missing blank lines weaken formatting. Nesting: Shallow conditionals and early returns make control flow easy to follow. Clarity of intent: Descriptive method names and docstrings explain the purpose, but the abbreviated attribute 'sig', shadowing of the built-in 'callable', and unrelated unused imports introduce minor distractions. Code length: Methods are concise, although repeated local imports and converting all parameters to a list add some verbosity. Action granularity: Each statement generally performs one clear action. Reading flow: Initialization followed by the two retrieval methods creates a natural progression; inconsistent spacing and the unnecessarily expanded return-annotation condition slightly interrupt it.