Sample
int-32c896a433eb-I11
Split eligible integer literals into pairs of short-named intermediate variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.691 | 0–1; higher is more readable |
| Dorn | 0.156 | 0–1; higher is more readable |
| Mi | 0.291 | 0–1; higher is more readable |
| LLOC | 39 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 11.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 14 | 0–20; mean of three runs |
| BTTF | 0.475 | 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. | 5976.307 | −197.218 |
| Source linesThe number of non-empty source lines. | 188 | +75.2 |
| 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 |
Intercept 8.87 + feature contributions = -120.078 (log-odds).
Score = sigmoid(-120.078) = 0.
| Score | 0.691 |
|---|
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. | 189 | −5.656 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 149 | +4.417 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 149 | −2.998 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 187.957 | +2.217 |
| 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. | 115.937 | −1.245 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 114.111 | +1.037 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.048 | +0.473 |
Intercept 0.07 + feature contributions = -1.686 (log-odds).
Score = sigmoid(-1.686) = 0.156.
| Score | 0.291 |
|---|
| Score | 39 |
|---|
Run 1
This code has moderate structure but suffers from several readability issues. The constructor overloads are logical but create excessive boilerplate with 10+ variations. The most problematic section is the newChild() method's bizarre indexing pattern using variables like 'a+b', 'c+d', 'f+g', 'h+i' to access array elements - this is confusing and obscures intent. Several lines exceed reasonable width, especially constructor chaining calls. Action granularity is inconsistent - some lines contain multiple operations while others are properly separated. The deprecated methods and class-level deprecation create ambiguity about whether the class should be used. Javadocs are present on some constructors but missing on others, creating inconsistent documentation. The imports are excessive but appropriate for the functionality. The method's parameter proliferation (8 parameters in one variant) indicates potential design issues. While the overall flow follows a logical constructor delegation pattern, the convoluted array indexing in newChild() significantly degrades clarity and maintainability.
Run 2
The code is structurally sound with clear constructor chaining, organized imports, and mostly useful method Javadocs. However, the `newChild` method is confusing. It uses cryptic, single-letter variables (`a`, `b`, `c`, `d`, etc.) to perform arithmetic offsets like `args[(a + b)]`, `argsLength > (c + d)`, and `args[(f + g)]`. These expressions obscure array indices and make the intent hard to follow. A reader must manually compute the values (index 0, 1, 2, etc.) instead of seeing descriptive constants. Additionally, using `args` as an `Object[]` without meaningful names for positions reduces clarity. Other parts of the class, especially the constructors and `rebuildSelectors`, are clear, but the `newChild` logic creates unnecessary cognitive load, violating clarity of intent and action granularity. The code has reasonable length and flat nesting, but the index arithmetic and mystery arguments lower readability.
Run 3
The code is partially readable due to clear class-level documentation, consistent constructor chaining, and a logical package structure. However, significant readability issues lower the score. The `newChild` method uses heavily obfuscated arithmetic (e.g., `args[(a + b)]` instead of `args[0]`, `argsLength > (c + d)` instead of `argsLength > 1`) which destroys clarity of intent. This is an anti-pattern for maintainability. While most constructors are straightforward, the class has too many overloaded constructors (9 total), creating redundancy. Naming and imports are standard, and line lengths are mostly acceptable, but the artificial variable declarations in `newChild` are confusing. The class is deprecated yet still complex, which adds ambiguity. Overall, the code is structurally organized but suffers from deliberate opacity in a critical method.
Run 1
Code Structure: Constructors, compatibility methods, and child creation are logically grouped, with straightforward delegation. Nesting: Shallow loops and conditionals keep control flow easy to follow. Clarity of intent: Descriptive API names and Javadocs explain most behavior, but newChild obscures simple argument indexes and thresholds behind meaningless variables and arithmetic. Positional Object... arguments and casts also require contextual knowledge. Code length: Numerous constructor overloads and repeated documentation increase scanning effort, while unnecessary constants make newChild longer than needed. Action granularity: Statements generally perform one action per line, and multiline calls remain understandable. Reading flow: The progression from constructors to operational methods is natural, but inconsistent continuation indentation and the artificial arithmetic interrupt otherwise clean reading.
Run 2
Code Structure: Constructors and lifecycle methods are logically grouped, although numerous overloads create repetition. Nesting: Very shallow; only a simple loop and two independent conditionals. Clarity of intent: Descriptive class, method, and parameter names plus Javadoc explain most behavior, but newChild uses meaningless variables and arithmetic to obscure straightforward array indices and length checks. Code length: Most methods are concise, but repeated constructor documentation and unnecessary constants inflate the class. Action granularity: Statements generally perform one action each, with constructor delegation keeping initialization focused. Reading flow: The progression from simple constructors to configurable overloads is natural, followed by operational methods; inconsistent parameter indentation and the contrived arithmetic in newChild interrupt that flow. Overall, readable API scaffolding is weakened by needless local complexity.
Run 3
Code Structure: Constructors and lifecycle methods are logically grouped, with delegation avoiding duplicated initialization. Nesting: Very shallow; only a loop and two independent conditionals. Clarity of intent: Class documentation, descriptive parameter names, and deprecation notices clarify purpose, but newChild uses meaningless variables and arithmetic expressions for simple array indices and thresholds, obscuring intent. Code length: Numerous constructor overloads and repetitive documentation increase scanning effort; unnecessary constants further inflate newChild. Action granularity: Statements generally perform one action each, although inline casts and factory calls add some visual complexity. Reading flow: Progression from simple constructors to advanced configuration and operational methods is natural, but inconsistent indentation, long signatures, positional varargs, and the artificial arithmetic interrupt readability.