Sample
int-a2c51b9db9fb-I02
Shorten method, parameter, and local names without collisions
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.65 | 0–1; higher is more readable |
| Dorn | 0.08 | 0–1; higher is more readable |
| Mi | 0.044 | 0–1; higher is more readable |
| LLOC | 103 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 7 | 0–20; mean of three runs |
| GPT-6.1 Sol | 11.67 | 0–20; mean of three runs |
| BTTF | 0.203 | 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. | 7764.104 | −256.215 |
| 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.406 | −6.609 |
Intercept 8.87 + feature contributions = -175.155 (log-odds).
Score = sigmoid(-175.155) = 0.
| Score | 0.65 |
|---|
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. | 141.98 | −2.349 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 196.839 | +2.342 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 141.965 | +1.486 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.085 | +0.117 |
Intercept 0.07 + feature contributions = -2.436 (log-odds).
Score = sigmoid(-2.436) = 0.08.
| Score | 0.044 |
|---|
| Score | 103 |
|---|
Run 1
The code has severe readability problems. Variable names like ssl2, ssl3, ssl4, rul, rul2, mat, mat2, res2, res3, distinguished2, to, to2, une, back2, back3, group2 are cryptic and fail to convey meaning. The RULE_PATTERN regex is extremely complex and opaque, making the core logic difficult to understand. The split() and parse() methods use a two-stage regex matching process that obscures the intent. Method names like to() and app() are ambiguous—to() suggests a conversion, but it's actually toString(), and app() is actually apply(). The escape() method contains convoluted back-reference manipulation with confusing variable names and multi-line comments explaining what should be self-evident from well-named code. The boolean parameters toLowerCase and toUpperCase in the Rule constructor are unclear and error-prone. The code relies heavily on magic regex group indices (mat2.group(2), mat2.group(4), mat2.group(6)) with no explanation of what each captures. Overall, the implementation is difficult to follow, maintain, and debug.
Run 2
The code has significant readability issues despite some logical organization. Variable names like 'ssl2', 'ssl3', 'ssl4', 'rul', 'rul2', 'res2', 'res3', 'mat2', 'back2', 'back3', 'to', 'to2', 'une', 'num' are cryptic and obscure intent. Method names are inconsistent ('to()' instead of 'toString()', 'app()' instead of 'apply()'). The regex pattern is extremely complex with nested groups, making it hard to understand. The 'escape' method has convoluted logic with unclear variable names and deep nesting. While the code follows a logical class structure and avoids excessive method length, the poor naming and complex regex significantly reduce clarity. Parameter names add confusion rather than documentation. The code requires domain knowledge of SSL principal mapping rules to partially decipher the intent.
Run 3
The code has significant readability issues. Variable names are cryptic and inconsistent (ssl2, ssl3, ssl4, rul, rul2, res2, mat2, back2, back3, une, num, to, to2, distinguished2), making intent unclear. The regex RULE_PATTERN is extremely complex and undocumented, obscuring the parsing logic. Method names like to() are misleading - toString() is misspelled and app() should be apply(). The parse() method has deeply nested conditionals and unclear group references. The escape() method contains convoluted back-reference handling with confusing variable names and complex while-loop logic. Parameter names like pat, rep, to, to2 provide no context. Constants are poorly named (SSL_PRINCIPAL_MAPPING_RULES referenced as DEFAULT_SSL_PRINCIPAL_MAPPING_RULES). The code mixes concerns without clear separation, and the overall structure feels tangled rather than logically organized. Some positives: methods are relatively short and each does roughly one conceptual task, but poor naming and complex regex patterns severely hamper readability.
Run 1
1. Code Structure: Responsibilities are logically separated into splitting, parsing, mapping, and an encapsulated Rule class. 2. Nesting: Mostly shallow, although back-reference handling introduces nested loops and conditionals. 3. Clarity of intent: Names such as ssl2, res3, back3, and to2 obscure meaning; dense regexes and numbered capture groups require substantial interpretation. Calling apply when only app exists, and using @Override on to rather than toString, further confuse intent. 4. Code length: Generally reasonable, but repetitive string construction and lengthy comments reduce concision. 5. Action granularity: Most statements perform one action per line, making individual steps easy to follow. 6. Reading flow: Methods follow a sensible progression, and early returns simplify navigation, but inconsistent naming, formatting, and method mismatches interrupt comprehension.
Run 2
Code Structure: Responsibilities are reasonably separated into splitting, parsing, mapping, and a nested Rule class. Nesting: Mostly shallow, with moderate nesting in back-reference handling and formatting. Clarity of intent: Descriptive class and field names help, but numbered variables such as ssl2, res3, and back3 obscure meaning. Dense regex patterns and numeric capture-group references require careful interpretation. The apply/app mismatch and invalid @Override on to() also undermine comprehension. Code length: Generally appropriate, though repetitive constructors and lengthy comments add bulk. Action granularity: Most statements perform one action per line, with a few dense expressions and long exception messages. Reading flow: Methods follow a logical processing sequence, but inconsistent naming, awkward indentation, and unexplained regex structure interrupt an otherwise straightforward flow.
Run 3
Code Structure: Well separated into splitting, parsing, mapping, and replacement escaping, with a dedicated Rule class. Nesting: Generally moderate, although escape combines a loop, conditionals, and an inner loop. Clarity of intent: Descriptive fields and explanatory comments help, but names such as ssl2, res3, back3, and to2 obscure meaning. Dense regexes and numbered capture groups require substantial interpretation. Calling r.apply while defining app, and using @Override on to instead of toString, introduce inconsistencies that undermine understanding. Code length: Mostly proportionate to the functionality, though repetitive constructors and verbose comments add bulk. Action granularity: Statements generally perform one action per line, making individual steps easy to follow. Reading flow: The overall progression is logical, but inconsistent naming, uneven formatting, long expressions, and complex back-reference handling interrupt readability.