Sample
int-3cd53ba7978f-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.612 | 0–1; higher is more readable |
| Dorn | 0.058 | 0–1; higher is more readable |
| Mi | 0.053 | 0–1; higher is more readable |
| LLOC | 135 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 3.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 9.67 | 0–20; mean of three runs |
| BTTF | 0.1 | 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. | 9902.781 | −326.792 |
| Source linesThe number of non-empty source lines. | 229 | +91.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.318 | −6.477 |
Intercept 8.87 + feature contributions = -232.799 (log-odds).
Score = sigmoid(-232.799) = 0.
| Score | 0.612 |
|---|
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. | 230 | −7.107 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 220 | +6.872 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 220 | −4.627 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 228.788 | +2.788 |
| 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. | 144.974 | −2.475 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 144.97 | +1.535 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.081 | +0.151 |
Intercept 0.07 + feature contributions = -2.793 (log-odds).
Score = sigmoid(-2.793) = 0.058.
| Score | 0.053 |
|---|
| Score | 135 |
|---|
Run 1
This code is nearly unreadable due to deliberate obfuscation. Critical logic uses meaningless variable names (a, b, c, d, etc.) with arithmetic to compute array indices, obscuring intent. Regex patterns are dense and lack comments. Methods like escapeLiteralBackReferences are extremely convoluted with unexplained magic numbers (e.g., final int u = 5; v = 5). Nesting is not excessive but action granularity is poor; each line attempts to hide simple operations through arithmetic. Code length is unnecessarily long due to obfuscated index calculations. Reading flow is severely disrupted. Although the class has a logical structure overall, the implementation details are hostile to readability. This appears intentionally sabotaged or severely neglected.
Run 2
This code is severely unreadable due to multiple severe issues. The most critical problem is the deliberate obfuscation of array indices using meaningless arithmetic operations like `(a + b)` instead of simply using `1`, making the code extremely difficult to understand and maintain. The regex patterns are complex and cryptic without explanation. Variable names like `a, b, c, d, e, f` provide no semantic meaning about their purpose. The nested while loops and conditionals create unnecessary complexity. Magic numbers appear throughout without constants or documentation. The code violates nearly every readability principle: poor structure, confusing nesting, unclear intent, unnecessary length through repetition, multiple actions per line in regex patterns, and completely unnatural reading flow. While the original logic might be sound, the implementation choices make it nearly impossible to comprehend without extensive reverse-engineering.
Run 3
This code is extremely unreadable due to deliberate obfuscation. The regex patterns are complex but acceptable; however, the variable naming (e.g., 'a + b', 'c + d', 'g + h') destroys clarity of intent, making arithmetic on meaningless constants appear magical. Action granularity is poor, as multiple operations are crammed into single lines. The heavy nesting in escapeLiteralBackReferences and cryptic magic numbers violate structure and nesting criteria. Code length is unnecessarily inflated by these obfuscations. Reading flow is disorganized, forcing readers to decode trivial offsets instead of understanding logic. While the original Apache Kafka source may be readable, this modified version intentionally sacrifices readability.
Run 1
Code Structure: Responsibilities are logically separated into splitting, parsing, mapping, and back-reference handling, with an appropriate nested Rule class. Nesting: Most methods have shallow control flow, although back-reference handling introduces several nested loops and conditions. Clarity of intent: Descriptive method names and explanatory comments help, but dense regexes, unnamed capture groups, and arbitrary variables such as a, b, and aa obscure otherwise simple constants. Code length: Numerous unnecessary declarations and arithmetic expressions substantially inflate the implementation. Action granularity: Most lines perform a single action, though some rule construction and replacement expressions require considerable unpacking. Reading flow: The overall progression is natural, but repeated constant arithmetic, verbose comments, and inconsistent whitespace interrupt comprehension. The architecture is readable, while local obfuscation makes implementation details unnecessarily difficult to follow.
Run 2
Code Structure: Sensibly divided into rule splitting, parsing, application, and a nested Rule class. Nesting: Mostly moderate, although back-reference handling introduces nested loops and conditionals. Clarity of intent: Descriptive method names and explanatory comments help, but the dense regex and numerous meaningless variables used to calculate simple constants substantially obscure intent. Code length: Unnecessarily inflated by arithmetic expressions and temporary constants that could be replaced with direct values or meaningful named constants. Action granularity: Generally one action per line, though some constructor calls and replacement expressions require considerable mental unpacking. Reading flow: The overall parse-and-apply sequence is natural, but repeated constant declarations interrupt it, particularly in parseRules and escapeLiteralBackReferences. Overall, the architecture is readable, while deliberate-looking arithmetic indirection makes implementation details cumbersome to follow.
Run 3
Code Structure: Responsibilities are logically separated into splitting, parsing, mapping, and replacement handling, with a cohesive Rule class. Nesting: Mostly shallow, although back-reference handling introduces several nested loops and conditionals. Clarity of intent: Descriptive method names and explanatory comments help, but cryptic variables (a through ah), arithmetic disguising simple constants, and dense regex patterns substantially obscure intent. Code length: Numerous unnecessary constant declarations and redundant parentheses inflate otherwise manageable code. Action granularity: Most statements perform one action per line, though complex constructor arguments and chained replacement operations require extra effort to interpret. Reading flow: The overall progression is natural, but repeated arithmetic indirection interrupts comprehension, especially in parsing and string-index manipulation.