Sample
int-ab394b9db989-I06
Invert eligible conditions and exchange their branches
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.603 | 0–1; higher is more readable |
| Dorn | 0.073 | 0–1; higher is more readable |
| Mi | 0.063 | 0–1; higher is more readable |
| LLOC | 103 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 4.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 9 | 0–20; mean of three runs |
| BTTF | 0.145 | 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. | 8298.877 | −273.863 |
| 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.49 | −6.736 |
Intercept 8.87 + feature contributions = -192.929 (log-odds).
Score = sigmoid(-192.929) = 0.
| Score | 0.603 |
|---|
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. | 188 | +5.766 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 188 | −3.893 |
| 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.98 | −2.476 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 196.849 | +2.342 |
| 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.087 | +0.094 |
Intercept 0.07 + feature contributions = -2.538 (log-odds).
Score = sigmoid(-2.538) = 0.073.
| Score | 0.063 |
|---|
| Score | 103 |
|---|
Run 1
The code is severely obfuscated by a pervasive 'if (!(condition)) {} else { ... }' pattern throughout, making even simple null checks and boolean branches confusing. The regex pattern RULE_PATTERN is complex and unexplained. Methods like escapeLiteralBackReferences contain convoluted logic with cryptic truncation behavior and confusing comments. Variable names are generally okay, but the unnatural conditional structure destroys reading flow and makes intent unclear. Nesting is deep in several places, and multiple actions sometimes occur on one line. While the code is somewhat organized into classes and methods, the execution paths are extremely hard to follow due to the inverted if-else blocks and lack of conventional structure. This would be very difficult to maintain or debug.
Run 2
The code is extremely difficult to read due to inverted conditionals throughout (e.g., `if (!(x)) {} else { ... }`), which obscures intent and breaks natural reading flow. The regex patterns are dense and unexplained, making them hard to understand. Formatting is inconsistent, with poorly indented nested conditionals and excessive line lengths. Multiple actions are packed into single lines (e.g., nested if/else in one line), and method names like `fromRules` add little semantic value. The `escapeLiteralBackReferences` method has convoluted logic and relies on external comments for comprehension. Nesting depth is shallow but the inverted logic makes control flow confusing. While the class is not overly long, the lack of clear structure, ambiguous conditional expressions, and poor formatting make it very hard to maintain or verify correctness.
Run 3
The code has several readability issues. The most significant problem is the pervasive use of inverted conditionals with empty if blocks and else blocks, such as 'if (!(condition)) {} else { ... }', which makes the logic extremely difficult to follow. This pattern appears throughout the code and forces readers to mentally invert conditions. The code also has excessive nesting in methods like escapeLiteralBackReferences and apply. The regular expression patterns are very dense with escape sequences and hard to understand at a glance. There are multiple actions on single lines, and the code contains unnecessary 'else' statements following 'if' blocks that already return. The method splitRules checks for null with 'if (!((sslPrincipalMappingRules == null))) {} else { ... }' which is extremely convoluted. While variable names are generally descriptive and the class structure is logically organized, the unusual conditional patterns, excessive nesting, and dense regex expressions make the code significantly harder to read than necessary. The code could be substantially improved by using standard conditional patterns, flattening nesting, and extracting complex logic into smaller methods.
Run 1
Code Structure: Responsibilities are reasonably separated into rule splitting, parsing, application, and back-reference handling. Nesting: Generally moderate, but inline nested conditionals and empty branches make control flow harder to follow. Clarity of intent: Descriptive method and field names help, while repeated negations, redundant parentheses, complex regexes, and numbered matcher groups obscure intent. Code length: Appropriate for the functionality overall, but empty conditional branches and verbose boolean expressions add unnecessary bulk. Action granularity: Most statements perform one action per line, though compressed conditional blocks undermine this consistency. Reading flow: The class progresses logically from construction to mapping and rule implementation, but inverted conditions repeatedly force readers to mentally reconstruct straightforward checks. Comments clarify the back-reference algorithm, partially offsetting the confusing syntax.
Run 2
Code Structure: Responsibilities are reasonably separated into rule splitting, parsing, application, and back-reference handling, with a cohesive Rule class. Nesting: Most methods have shallow nesting, but inline nested conditionals and empty branches make control flow harder to follow. Clarity of intent: Descriptive method and field names help, while repeated negations, redundant parentheses, complex regexes, and numbered capture groups obscure intent. Code length: Overall length is reasonable for the functionality, but empty if blocks and verbose conditional forms add unnecessary clutter. Action granularity: Most statements perform one action per line; several compressed conditional blocks violate this otherwise consistent style. Reading flow: Method organization and explanatory comments provide guidance, but inverted conditions and logic placed in else branches repeatedly interrupt natural reading.
Run 3
Code Structure: Responsibilities are logically separated into rule splitting, parsing, application, and back-reference handling. Nesting: Generally moderate, but compressed nested conditionals and empty branches make it harder to follow. Clarity of intent: Descriptive method and field names help, while repeated negations, redundant parentheses, opaque regexes, and numbered capture groups obscure intent. Code length: Reasonable for its responsibilities, though empty branches and verbose conditional forms add unnecessary clutter. Action granularity: Most statements perform one action per line, but several conditional blocks are packed onto single lines. Reading flow: Method organization is natural and comments explain complex replacement behavior, but inverted conditions force repeated mental simplification and disrupt otherwise straightforward control flow.