Sample
pyint-dbcf7536b486-I11
Split eligible integer literals into pairs of short-named intermediate variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.334 | 0–1; higher is more readable |
| Mi | 0.738 | 0–1; higher is more readable |
| LLOC | 60 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 12.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.517 | 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. | 3920 | −129.36 |
| Source linesThe number of non-empty source lines. | 197 | +78.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.035 | −6.053 |
Intercept 8.87 + feature contributions = -47.743 (log-odds).
Score = sigmoid(-47.743) = 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. | 198 | −5.974 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 170 | +5.143 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 170 | −3.48 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 196.962 | +2.343 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.054 | +0.415 |
| 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. | 76.97 | +0.405 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 73.869 | +0.387 |
Intercept 0.07 + feature contributions = -0.691 (log-odds).
Score = sigmoid(-0.691) = 0.334.
| Score | 0.738 |
|---|
| Score | 60 |
|---|
Run 1
The code is structured with clear sections for imports, class definition, and methods, but readability suffers due to overly verbose and repetitive constructor setup. While nesting is minimal and methods are generally flat, the __init__ and __attrs_attrs__ definitions involve many positional arguments without immediate clarity. Intent is partially obscured by low-level counter logic (a=2, b=-1) and complex data structures. Code length is unnecessarily long, especially in the Attribute construction tuples. Action granularity is mostly one assignment per line, which is positive, but the overall reading flow is disrupted by long argument lists and symbolic placeholders. The class docstring and method docstrings help, but the heavy use of internal machinery without simplified abstractions reduces clarity.
Run 2
The code has a clear structure with imports, a class, and methods, but readability suffers from several issues. The __attrs_attrs__ construction uses a complex generator expression inside a tuple, making it hard to follow. The __init__ method has cryptic variable assignments (a=2, b=-1) that obscure intent, and the counter increment logic is unnecessarily convoluted. Nesting is moderate but the large tuple construction adds visual noise. Action granularity is mostly one per line, which is good, but the converter method's lambda and pipeline logic reduces clarity. Documentation strings are helpful but do not compensate for the dense, repetitive attribute definitions. Overall, the code is functional but could be more readable with clearer naming, simpler counter logic, and reduced repetition in attribute declarations.
Run 3
The code is generally well-structured with clear class and method definitions, but several factors reduce readability. The __attrs_attrs__ tuple is complex and difficult to parse due to deeply nested generator expressions and verbose constructor calls. The __init__ method has cryptic variable names (a, b) and an obscure counter increment pattern (cls_counter += (a + b)) that obscures intent. While most methods are concise and well-documented, the converter method contains nested lambdas that are hard to follow, and the heavy use of positional arguments in Attribute constructors (15+ parameters) significantly impairs clarity. Nesting is mostly flat but action granularity suffers in places like the generator expression. Overall, the code mixes clear, well-documented sections with dense, cryptic initialization patterns.
Run 1
Code Structure: The class is logically organized into metadata, initialization, and focused decorator methods, although the extensive imports add clutter. Nesting: Control flow is shallow; only the metadata construction is visually layered. Clarity of intent: Descriptive field names and helpful docstrings explain most behavior, but the arbitrary a and b variables obscure a simple counter increment, and external helpers require context. Code length: The long constructor and repeated Attribute configuration are verbose, though mostly justified by the represented data. Action granularity: Statements generally perform one action per line, making assignments and state changes easy to follow. Reading flow: Methods progress naturally from checks to updates to returns, but lengthy declarative setup delays the core behavior and slightly interrupts readability.
Run 2
Code Structure: The class is logically organized into metadata, initialization, and focused decorator methods, although the large import block and repeated Attribute configuration add clutter. Nesting: Control flow is shallow, with simple conditionals; the metadata comprehension is somewhat harder to scan. Clarity of intent: Descriptive field names and useful docstrings explain the class and methods well. However, incrementing the counter through arbitrary variables a and b obscures a straightforward operation, and external definitions require context. Code length: Mostly justified by attribute configuration, but repeated keyword arguments and unnecessary counter arithmetic reduce concision. Action granularity: Statements generally perform one action per line, making assignments easy to follow. Reading flow: Method ordering and consistent formatting support natural reading, though the lengthy metadata setup delays reaching behavior, and names such as repr, hash, and type shadow built-ins.
Run 3
Code Structure: Logically organized into a documented class, attribute declarations, initialization, and focused decorator methods. Nesting: Mostly flat, with simple conditionals; the tuple expansion and generator expression add moderate complexity. Clarity of intent: Descriptive names and docstrings explain the purpose well, but the unnecessary a and b variables obscure a simple counter increment, and externally defined helpers require context. Code length: Explicit attribute configuration and constructor assignments are lengthy but largely justified; the counter arithmetic and numerous imports add avoidable noise within this snippet. Action granularity: Statements generally perform one action per line, making state changes easy to follow. Reading flow: Methods follow a consistent pattern and read naturally, although the large metadata declaration delays reaching the behavioral code, and parameter names such as repr, hash, and type shadow built-ins.