Sample
int-8d3e58001186-SRC
Unmodified source class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.622 | 0–1; higher is more readable |
| Dorn | 0.08 | 0–1; higher is more readable |
| Mi | 0.053 | 0–1; higher is more readable |
| LLOC | 103 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 13.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.2 | 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. | 7639.316 | −252.097 |
| 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.473 | −6.71 |
Intercept 8.87 + feature contributions = -171.137 (log-odds).
Score = sigmoid(-171.137) = 0.
| Score | 0.622 |
|---|
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.985 | −2.476 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 196.815 | +2.341 |
| 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.078 | +0.187 |
Intercept 0.07 + feature contributions = -2.445 (log-odds).
Score = sigmoid(-2.445) = 0.08.
| Score | 0.053 |
|---|
| Score | 103 |
|---|
Run 1
The code has clear class responsibilities and reasonable method decomposition, but readability is hurt by several factors. The regex `RULE_PATTERN` is highly obscure, making parsing logic difficult to understand. `parseRules` uses regex groups whose meanings are not documented, reducing clarity of intent. Nested `if/else if` in `apply` is mild but acceptable. The `escapeLiteralBackReferences` method is long and the backreference truncation logic is complex and only briefly commented. Comments are helpful but lengthy. Some lines are dense, especially regex pattern definitions and the nested `Rule` constructor call. Action granularity is mostly one action per line, but regex-heavy lines pack too much. Overall, the code is maintainable but would benefit from clearer parsing abstractions and better explanation of the rule grammar.
Run 2
The code has a clear class structure and methods are logically organized, but the regex pattern is extremely dense and hard to read. Nesting is manageable but the `apply` method and `escapeLiteralBackReferences` method contain multiple conditional checks. Intent is mostly clear from method names, but the regex rules and back-reference logic lack inline documentation. Code length is moderate but some sections feel verbose. Action granularity is reasonable, with mostly one action per line. Reading flow is decent but interrupted by complex regex parsing and unclear error handling. Overall, it's readable but could benefit from simplifying the regex pattern and adding comments.
Run 3
The code has a clear overall structure with well-separated methods and classes. However, readability is hindered by several factors: the regex patterns are extremely complex and poorly documented, making intent difficult to understand immediately. The RULE_PATTERN uses heavy escaping without explanation. The parseRules method throws identical exceptions with slightly different messages, which could be consolidated. There is moderate nesting in methods like escapeLiteralBackReferences, which contains while loops and conditionals that require careful reading. Action granularity is mostly good, but some lines combine multiple operations. The comments explaining back reference escaping logic are helpful, yet the algorithm itself remains complex. The code would benefit from extracting the regex explanation into documentation or breaking complex logic into smaller, named helper methods to improve clarity.
Run 1
Code Structure: Responsibilities are logically separated into splitting, parsing, mapping, and a dedicated Rule class. Nesting: Mostly shallow, though back-reference handling and rule formatting introduce moderate nesting. Clarity of intent: Descriptive method names and explanatory comments help, but dense regular expressions, numbered capture groups, and abbreviated variables such as r and m require extra interpretation. Code length: Generally appropriate for the functionality, with some verbose initialization, comments, and formatting logic. Action granularity: Statements generally perform one action per line; a few long expressions combine matching, replacement, or error construction. Reading flow: The progression from configuration parsing to rule application is natural, with early returns simplifying control flow. Inconsistent comment formatting, long lines, and the intricate back-reference algorithm slightly interrupt readability.
Run 2
Code Structure: Well organized into rule splitting, parsing, application, and a cohesive nested Rule class. Nesting: Mostly shallow, with moderate nesting in back-reference handling and string formatting. Clarity of intent: Descriptive method names and explanatory comments communicate the purpose, but dense regular expressions, numbered capture groups, and abbreviated variables obscure details. Code length: Generally proportionate to the functionality, though constructors and formatting logic are somewhat repetitive and several lines are long. Action granularity: Most statements perform one action per line; a few expressions combine matching, escaping, and replacement operations. Reading flow: Methods follow a natural progression from configuration to parsing and execution, with early returns simplifying control flow. Minor formatting inconsistencies and the intricate back-reference algorithm interrupt otherwise smooth reading.
Run 3
Code Structure: Well organized into rule splitting, parsing, application, and a dedicated nested Rule class. Nesting: Generally shallow, though back-reference handling and rule formatting introduce moderate nesting. Clarity of intent: Descriptive method and field names communicate purpose, and comments explain tricky replacement behavior; however, dense regular expressions, numeric capture-group references, and abbreviated variables obscure details. Code length: Mostly appropriate for the functionality, with some verbose initialization, formatting logic, and comments. Action granularity: Statements generally perform one action per line, although a few compound expressions combine matching, replacement, and escaping. Reading flow: The progression from construction through parsing to application is natural, supported by consistent spacing and early returns. Long exception expressions and the intricate back-reference algorithm interrupt otherwise smooth reading.