Sample
int-1b5093bd50e9-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.602 | 0–1; higher is more readable |
| Dorn | 0.057 | 0–1; higher is more readable |
| Mi | 0.109 | 0–1; higher is more readable |
| LLOC | 127 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 9 | 0–20; mean of three runs |
| GPT-6.1 Sol | 12.33 | 0–20; mean of three runs |
| BTTF | 0.261 | 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. | 9843.448 | −324.834 |
| Source linesThe number of non-empty source lines. | 221 | +88.4 |
| 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.603 | −6.904 |
Intercept 8.87 + feature contributions = -234.468 (log-odds).
Score = sigmoid(-234.468) = 0.
| Score | 0.602 |
|---|
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. | 222 | −6.824 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 212 | +6.596 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 212 | −4.444 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 220.808 | +2.677 |
| 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.959 | −2.475 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 144.968 | +1.535 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.09 | +0.066 |
Intercept 0.07 + feature contributions = -2.799 (log-odds).
Score = sigmoid(-2.799) = 0.057.
| Score | 0.109 |
|---|
| Score | 127 |
|---|
Run 1
The code suffers from several readability issues. Most critically, every method contains an obfuscated, meaningless assertion line (e.g., 'if (((0x2847 ^ 0x2847) != 0)) { throw new AssertionError(); }') which adds noise and destroys reading flow. Naming is generally good, and regex constants are well-placed, but the complex regex patterns are difficult to parse without comments. The escapeLiteralBackReferences method has dense inline comments explaining a non-trivial algorithm, but it remains highly nested and hard to follow. Action granularity is mostly one-action-per-line, but the constructor calls in parseRules span multiple lines in a cramped style. Structure is logical overall, but the artificial assertions and intricate regex handling overshadow clarity. Code length is reasonable for the functionality, but the obfuscation artifacts alone significantly reduce readability.
Run 2
The code suffers from severe readability issues. Obscure dead-code assertions like 'if (((0x2847 ^ 0x2847) != 0)) { throw new AssertionError(); }' are scattered throughout, adding noise and confusing the reader. The constructor and methods are unnecessarily long and mix concerns (parsing, validation, and transformation). The regex patterns are complex and poorly documented, making intent ambiguous. While the overall structure is somewhat organized into methods, the nested logic in `apply` and `escapeLiteralBackReferences` is hard to follow. Action granularity is inconsistent, with dense lines combining multiple operations. The reading flow is disrupted by the assertions and verbose comments. Basic formatting and indentation are present, but they don't compensate for the cluttered logic and dead code. Overall, the code is difficult to read, maintain, and debug.
Run 3
The code is generally well-structured with clear separation of concerns: parsing rules, transforming names, and handling exceptions. It demonstrates reasonable action granularity and reading flow. However, there are several readability issues. The complex regex patterns (RULE_PATTERN, RULE_SPLITTER, RULE_PARSER) make the parsing logic hard to understand at a glance. The odd 'assertion' statements with XOR operations and the conditional 'throw new AssertionError()' are confusing and disrupt the reading flow — they appear to be added for obfuscation or compliance but hurt clarity. The escapeLiteralBackReferences method has dense logic with non-obvious integer manipulation and could be broken down further. There is also some inconsistency in brace placement between the class constructor and other methods. While the core logic is readable and well-organized overall, these issues prevent the code from being highly readable.
Run 1
Code Structure: Responsibilities are logically separated into splitting, parsing, mapping, and rule application, with a cohesive nested Rule class. Nesting: Mostly shallow, although back-reference handling introduces nested loops and conditionals. Clarity of intent: Descriptive method names and explanatory comments help, but dense regular expressions, numbered capture groups, and repeated always-false hexadecimal assertions obscure intent. Code length: Generally reasonable for the functionality, but redundant assertions and verbose string construction add unnecessary bulk. Action granularity: Most meaningful operations occupy separate lines; injected assertions compress conditions and throws onto single lines. Reading flow: The overall progression is natural, but unindented dead-code checks repeatedly interrupt it, while long expressions and inconsistent formatting slow scanning.
Run 2
Code Structure: Responsibilities are logically separated into splitting, parsing, mapping, and an encapsulated Rule class. Nesting: Mostly shallow, though back-reference handling introduces nested loops and conditionals. Clarity of intent: Descriptive method names and explanatory comments help, but dense regexes, numbered capture groups, and abbreviated variables obscure details. Repeated always-false XOR assertions add misleading noise. Code length: Generally reasonable for the functionality, but redundant assertions and verbose comments unnecessarily expand it. Action granularity: Most lines perform one action; injected assertions compress a condition and throw onto one poorly indented line. Reading flow: Method ordering and early returns support natural progression, but inconsistent indentation, long expressions, and repeated dead checks interrupt it.
Run 3
Code Structure: Responsibilities are logically separated into splitting, parsing, mapping, and rule handling. Nesting: Mostly shallow, although back-reference processing and rule formatting contain nested control flow. Clarity of intent: Descriptive method names and explanatory comments help, but dense regular expressions, numbered capture groups, and repeated always-false XOR assertions obscure intent. Code length: Generally reasonable, but injected assertions and some verbose comments add unnecessary bulk. Action granularity: Most meaningful statements perform one action per line; assertion lines compress conditions and throws together. Reading flow: The overall progression is natural, but unindented assertions repeatedly interrupt it, and long expressions require extra effort to decode.