Sample
pyint-1b68c4669d34-I05
Rewrite eligible decimal integer literals in hexadecimal notation
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.001 | 0–1; higher is more readable |
| Dorn | 0.75 | 0–1; higher is more readable |
| Mi | 0.561 | 0–1; higher is more readable |
| LLOC | 27 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 15 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.384 | 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. | 49 | +19.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.224 | −6.336 |
Intercept 8.87 + feature contributions = -7.438 (log-odds).
Score = sigmoid(-7.438) = 0.001.
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. | 49 | −0.699 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 40 | +0.646 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 40 | −0.497 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.049 | +0.463 |
| 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. | 75.96 | +0.448 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 74.46 | +0.397 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 48.688 | +0.271 |
Intercept 0.07 + feature contributions = 1.1 (log-odds).
Score = sigmoid(1.1) = 0.75.
| Score | 0.561 |
|---|
| Score | 27 |
|---|
Run 1
The code is generally readable with a clear class purpose and well-defined methods. However, there are some inconsistencies that affect clarity: repeated local imports of 'inspect' (three times) could be consolidated; the use of 'params[0x0]' is cryptic and should be 'params[0]'; the get_return_type method contains an unnecessary multi-line condition that could be simplified. The class structure is logical, and nesting is minimal, but the repeated imports and unusual indexing break reading flow. Action granularity is mostly one action per line, which is good. Overall, the code is understandable but could be improved for consistency and clarity.
Run 2
The code is generally readable with clear intent and logical organization. The class has a single responsibility, methods are well-named, and docstrings explain purpose. However, there are some issues: repeated imports of `inspect` inside methods (though likely intentional for lazy loading, it adds noise), the hexadecimal `0x0` index instead of `0` is unnecessary and confusing, and the `if not self.sig` guard in `get_first_param_type` could be combined with the return type method for consistency. The nested imports and slight inconsistencies slightly reduce readability, but overall the code is concise, follows a flat structure, and has good action granularity.
Run 3
The code has a clear purpose and decent docstrings, but readability is hindered by several issues. The structure is logical but verbose for its simple task. Imports are scattered inside methods instead of being top-level, which disrupts the reading flow and obscures dependencies. The condition `params[0x0].annotation` uses an unnecessary hex literal for index 0, reducing clarity. Boolean logic like `if not self.sig: return None` is acceptable, but the class overall adds complexity without clear benefit. Nesting is minimal, and action granularity is mostly one action per line. However, the repeated local `import inspect` statements and the unused inherited imports (`Mapping`, `Sequence`, `Callable`, `_GenericAlias`) reduce overall readability. The code is concise but not as clean or intuitive as it could be—refactoring imports and simplifying logic would make it notably clearer.
Run 1
Code Structure: The class logically groups signature extraction and annotation access into small methods, though unused imports add clutter. Nesting: Shallow conditionals and early returns keep complexity low. Clarity of intent: Descriptive method names and docstrings explain the purpose; however, params[0x0] is needlessly unusual, and naming a parameter callable shadows a built-in. Code length: Generally concise, with some repetition from local inspect imports and explicit fallback returns. Action granularity: Each line performs a single clear action. Reading flow: Initialization followed by parameter and return annotation access creates a natural progression, slightly interrupted by repeated imports and an unnecessarily split conditional.
Run 2
Code Structure: A focused class groups signature extraction and annotation access into small, logically organized methods; several unused imports add clutter. Nesting: Shallow conditionals and early returns keep control flow easy to follow. Clarity of intent: Descriptive method names and docstrings explain the purpose, though hexadecimal indexing (0x0) is unnecessarily obscure and the parameter name callable shadows a built-in. Code length: Generally concise, but repeated local inspect imports and converting all parameters to a list introduce minor verbosity. Action granularity: Statements generally perform one action per line. Reading flow: Initialization followed by parameter and return annotation access reads naturally; the expanded return-type condition slightly interrupts an otherwise straightforward flow.
Run 3
Code Structure: A focused class separates signature extraction from parameter and return annotation access, with logical method ordering. Nesting: Minimal nesting and an early return make control flow easy to follow. Clarity of intent: Descriptive method names and docstrings explain the purpose, although 'sig' is abbreviated, 'callable' shadows a built-in, and '0x0' unnecessarily obscures a simple zero index. Code length: Concise overall, but unused top-level imports, repeated local inspect imports, and converting parameters to a list add clutter. Action granularity: Each statement performs a distinct action, without compressed multi-action lines. Reading flow: Initialization followed by accessor methods reads naturally; the multiline return-annotation condition slightly interrupts an otherwise straightforward flow.