Sample
pyint-ce08f1222318-I02
Shorten method, parameter, and local names without collisions
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.892 | 0–1; higher is more readable |
| Mi | 0.561 | 0–1; higher is more readable |
| LLOC | 60 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 7.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 13.67 | 0–20; mean of three runs |
| BTTF | 0.416 | 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. | 4502.379 | −148.578 |
| Source linesThe number of non-empty source lines. | 162 | +64.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.624 | −6.936 |
Intercept 8.87 + feature contributions = -81.844 (log-odds).
Score = sigmoid(-81.844) = 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. | 163 | −4.735 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 135 | +3.932 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 161.961 | +1.854 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 101.939 | +0.84 |
| 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. | 101.926 | −0.652 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.055 | +0.408 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = 2.116 (log-odds).
Score = sigmoid(2.116) = 0.892.
| Score | 0.561 |
|---|
| Score | 60 |
|---|
Run 1
The code is a mix of clear structure and severely obfuscated naming. The imports are logically grouped and the class docstring is excellent, but the parameter names in '__init__' (met, url2, hea, fil, dat, par, aut, coo, hoo, jso) are ambiguous and break clarity of intent. The use of suffix '2' (e.g., url2, p2, k2, v2) further obscures meaning, suggesting renaming artifacts. Nesting is generally flat and action granularity is mostly one action per line, which aids readability. However, abbreviations like 'pre' instead of 'prepare' and shortened type annotations reduce clarity. The mixed naming style—full names for type hints but truncated names for variables—creates confusion. Overall structure is professional, but the naming significantly harms readability and maintainability.
Run 2
The code has some readable aspects, such as good type hints, clear imports, and a well-documented class. However, it is severely undermined by poor naming conventions and inconsistent style. Critical parameters and local variables are abbreviated to near-meaningless names (e.g., 'met', 'url2', 'hea', 'fil', 'dat', 'par', 'aut', 'coo', 'hoo', 'jso', 'k2', 'v2', 'p2'), making the logic hard to follow and forcing the reader to constantly map abbreviations to their intended meanings. The class attributes retain full names, but the constructor and methods do not, creating a confusing mismatch. Additionally, the method name 'pre' is ambiguous, and the overall action granularity and reading flow suffer from the lack of descriptive identifiers. While the structure is flat and imports are organized, the unclear intent and poor naming significantly lower readability.
Run 3
The code is largely unreadable due to poor naming conventions and unclear intent. Parameters in `__init__` use cryptic abbreviations like `met`, `url2`, `hea`, `fil`, `dat`, `par`, `aut`, `coo`, `hoo`, and `jso`, which obscure meaning. The `pre` method and variables `p2`, `k2`, `v2` are ambiguous. Imports are extensive and somewhat disorganized, making the top of the file noisy. The class docstring is helpful, but the implementation does not match its clarity. Structure and nesting are acceptable, but readability is severely reduced by the unnecessary renaming of clear parameters to short, non-descriptive alternatives. Action granularity is mostly one action per line, but the unnatural flow and unclear references hinder comprehension. Overall, the code appears intentionally obfuscated rather than optimized for readability.
Run 1
Code Structure: The class is logically organized into documentation, annotations, initialization, representation, and request preparation, but the extensive import block distracts from the small implementation. Nesting: Minimal nesting makes control flow easy to follow. Clarity of intent: Descriptive attributes, type hints, and documentation help, but abbreviated parameters such as met, hea, and jso and names like p2 obscure meaning. The method pre also conflicts with the documented prepare usage, and documented parameter names do not match the constructor. Code length: The implementation is concise, though imports and documentation dominate the snippet. Action granularity: Statements generally perform one action per line, with clear assignments and readable multiline calls. Reading flow: Initialization and preparation follow a natural sequence, but inconsistent naming and base classes or types not defined or imported in the snippet interrupt comprehension.
Run 2
Code Structure: The class is logically organized into documentation, attributes, initialization, representation, and request preparation, although the extensive imports obscure its focus. Nesting: Control flow is shallow, with only one simple loop. Clarity of intent: Type annotations, descriptive attributes, and documentation help, but abbreviated parameters such as met, hea, and jso and names like pre and p2 reduce clarity. Documentation refers to prepare() and descriptive parameter names that do not match the implementation. Code length: The methods are concise, but many imports are unused in this snippet and the documentation is disproportionately long. Action granularity: Statements generally perform one action per line, and multiline arguments are easy to scan. Reading flow: Initialization and preparation follow a natural sequence, but inconsistent naming and dependencies not defined or imported in the snippet interrupt comprehension.
Run 3
Code Structure: The class is logically organized into attributes, initialization, representation, and request preparation, though the extensive imports obscure the small implementation. Nesting: Minimal nesting makes control flow easy to follow. Clarity of intent: Type annotations, descriptive instance attributes, and documentation clarify the purpose, but abbreviated parameters such as met, hea, and jso, temporary names like p2, and the method name pre reduce clarity. Documentation refers to prepare() and full parameter names that do not match the implementation, creating confusion. Code length: Methods are concise, but the import block and documentation are disproportionately large for this excerpt. Action granularity: Statements generally perform one action per line, with straightforward assignments and initialization. Reading flow: Initialization proceeds naturally from defaults to hooks to attributes, followed by preparation; however, missing definitions for referenced classes in the excerpt and inconsistent naming interrupt comprehension.