Sample
int-d9bc4553f0eb-I13
Lower every eligible classic and enhanced for loop to a while loop
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.595 | 0–1; higher is more readable |
| Dorn | 0.072 | 0–1; higher is more readable |
| Mi | 0.05 | 0–1; higher is more readable |
| LLOC | 107 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 10.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 14 | 0–20; mean of three runs |
| BTTF | 0.196 | 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. | 8169.975 | −269.609 |
| Source linesThe number of non-empty source lines. | 205 | +82 |
| 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.471 | −6.707 |
Intercept 8.87 + feature contributions = -185.446 (log-odds).
Score = sigmoid(-185.446) = 0.
| Score | 0.595 |
|---|
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. | 206 | −6.257 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 196 | +6.042 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 196 | −4.077 |
| 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.981 | −2.476 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 204.795 | +2.453 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 144.961 | +1.534 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.081 | +0.158 |
Intercept 0.07 + feature contributions = -2.553 (log-odds).
Score = sigmoid(-2.553) = 0.072.
| Score | 0.05 |
|---|
| Score | 107 |
|---|
Run 1
The code generally follows logical organization with classes and methods split by responsibility, but has some readability issues. The regex patterns are highly complex and opaque, making intent hard to understand. The parseRules and getName methods have unnecessary block scoping with manual iterator loops instead of for-each, adding clutter. The nested while loops with index truncation logic in escapeLiteralBackReferences are deeply nested and difficult to follow. Action granularity is mostly one action per line, but some lines are dense. Reading flow improves in the Rule class (apply, toString) but degrades in the escaping logic. Parameter reassignment in splitRules is minor. Overall, readable enough for experienced developers familiar with regex, but less accessible to others.
Run 2
The code is moderately readable but has several issues. Structure is logical with clear class separation, but the odd standalone blocks around iterators (lines in parseRules and getName) disrupt readability and suggest decompiled or generated code. Nesting is mostly flat, though the while loop in escapeLiteralBackReferences adds complexity. Intent is generally clear from method names, but the complex regex patterns and inline comments are dense. Code length is reasonable but some methods (escapeLiteralBackReferences) are unnecessarily long. Action granularity is mostly one action per line, which is good. Reading flow suffers from inconsistent formatting: misaligned indentation in the rule parsing block and verbose iterator usage instead of for-each loops. The toString method is clear, but error handling and null checks are somewhat scattered. Overall, it's understandable but could be significantly improved with cleaner loops, consistent formatting, and better decomposition of the complex back-reference method.
Run 3
The code suffers from excessive length, awkward iteration constructs, and tangled logic. The parseRules and getName methods use obfuscated 'loopIterator' blocks instead of natural for-each loops, disrupting reading flow and adding unnecessary nesting. The regex patterns are dense and lack explanatory comments, making intent unclear. The escapeLiteralBackReferences method is overly complex with nested loops and unclear truncation logic. While the class structure is logical (mapper, rules, parsing), the implementation obscures the purpose. The action granularity is inconsistent—some lines are clear, but others pack multiple operations. The verbose comments in escapeLiteralBackReferences help slightly, but the method remains hard to follow. Overall, the code requires significant simplification and clearer naming to be considered readable.
Run 1
Code Structure: Responsibilities are logically separated into splitting, parsing, mapping, and a nested Rule class. Nesting: Generally moderate, but redundant scope blocks and explicit iterator loops add unnecessary depth. Clarity of intent: Descriptive method names and explanatory back-reference comments help, while dense regular expressions, numbered capture groups, and abbreviated variables obscure details. Code length: Mostly justified, although iterator boilerplate, casts, and repetitive string construction could be simplified. Action granularity: Statements generally perform one action per line; a few long expressions require extra effort to unpack. Reading flow: The progression from configuration to rule application is natural, but inconsistent indentation, extra braces, and complex replacement handling interrupt readability.
Run 2
Code Structure: Responsibilities are logically separated into splitting, parsing, mapping, and a nested Rule class. Nesting: Mostly moderate, but unnecessary iterator scope blocks and nested back-reference handling add complexity. Clarity of intent: Descriptive method and field names help, while dense regex patterns, unexplained capture-group indices, and short variables such as r and m obscure details. Code length: Reasonable overall, though explicit untyped iterators, casts, and redundant blocks are unnecessarily verbose compared with enhanced for-loops. Action granularity: Statements generally perform one action per line, with a few dense constructor calls and replacement expressions. Reading flow: The split-parse-apply sequence is natural, but inconsistent indentation, long exception lines, and lengthy comments interrupt scanning. Overall, the design is understandable, but parsing details and mechanical verbosity reduce readability.
Run 3
Code Structure: Responsibilities are logically separated into rule splitting, parsing, mapping, and a nested Rule class. Nesting: Mostly moderate, but unnecessary scope blocks and explicit iterator loops add indentation and clutter. Clarity of intent: Descriptive method names and explanatory back-reference comments help, while dense regex patterns, numeric capture-group references, and short names such as r and m obscure details. Code length: Reasonable overall, though iterator boilerplate, redundant parentheses, and verbose string construction could be simplified. Action granularity: Generally one action per line, making operations easy to follow, although some expressions and exception messages are long. Reading flow: The progression from configuration parsing to rule application is natural, but inconsistent indentation and the intricate back-reference handling interrupt readability.