Sample
int-7ca13fc9533a-I03
Replace method, parameter, and local names with length-matched, meaningful but unrelated names
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.626 | 0–1; higher is more readable |
| Dorn | 0.079 | 0–1; higher is more readable |
| Mi | 0.038 | 0–1; higher is more readable |
| LLOC | 103 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 5.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 9.33 | 0–20; mean of three runs |
| BTTF | 0.158 | 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. | 7782.424 | −256.82 |
| 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.456 | −6.685 |
Intercept 8.87 + feature contributions = -175.835 (log-odds).
Score = sigmoid(-175.835) = 0.
| Score | 0.626 |
|---|
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.808 | +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.079 | +0.175 |
Intercept 0.07 + feature contributions = -2.456 (log-odds).
Score = sigmoid(-2.456) = 0.079.
| Score | 0.038 |
|---|
| Score | 103 |
|---|
Run 1
The code structure is logical but suffers from confusing naming conventions. Method names like 'findEvent', 'deliver', 'organize', 'check', and 'sendMode' don't reflect their actual purposes (parsing, mapping, toString, etc.), making intent unclear. Variable names like 'client', 'summary', 'cache', 'status', 'message', 'balance', 'remoteToken', 'cachedCache', 'finalStatus', and 'nextValue' are misleading or meaningless. The code is moderately nested but not excessively. Line length is generally reasonable, though the regex pattern string is extremely long. Action granularity is mostly one action per line. Reading flow is disrupted by the semantic mismatch between names and functionality. The class appears to be a renamed SSH/SSL principal mapper with obfuscated identifiers, which significantly reduces readability despite otherwise clear structure.
Run 2
The Java class has severe readability issues despite having a clear, single-purpose role (SSL principal mapping). Variable and method names are misleading or unrelated to their behavior (e.g., 'deliver', 'organize', 'findEvent', 'check', 'sendMode', 'validateAccount'), which obscures intent. The code is long and verbose, with unnecessary null checks and convoluted back-reference handling that adds complexity. Nesting is moderate but the flow is disorganized due to poor naming, scattered comments, and inconsistent formatting. The class mixes parsing, mapping, and exception handling without clear separation. While the overall structure is somewhat logical, the naming and ambiguous terms make the code hard to follow and maintain.
Run 3
The code is difficult to read due to severe naming problems: methods like `findEvent`, `parseIndex`, `deliver`, `organize`, `check`, `validateAccount`, and `sendMode` obscure their actual purposes (e.g., `deliver` actually maps a principal, `organize` is `toString`). Variable names such as `pendingRequest`, `client`, `summary`, `cache`, `step`, `message`, `balance`, `remoteToken`, `cachedCache`, `finalStatus`, `region`, `key`, `total`, `activePath`, `primaryScore`, `item`, and `finalToken` are misleading or meaningless, severely reducing clarity of intent. While the code structure itself is not deeply nested (a positive for criterion 2) and line length is mostly reasonable (criterion 4), the pervasive semantic mislabeling destroys reading flow (criterion 6) and makes the logic ambiguous. Action granularity is acceptable. The regular expressions, while complex, are at least defined as constants. Overall, the code is functionally structured but unreadable due to chaotic naming.
Run 1
Code Structure: Parsing, mapping, and rule handling are reasonably separated into methods and a nested class. Nesting: Mostly shallow, although back-reference validation and rule formatting introduce moderate nesting. Clarity of intent: Unrelated names such as parseIndex, deliver, region, and primaryScore obscure SSL principal mapping. The call to map.apply conflicts with the defined check method, and invalid @Override methods further confuse the intended interface. Dense regexes and numeric capture-group references require careful interpretation. Code length: Generally appropriate, but repetitive formatting logic and lengthy comments add some verbosity. Action granularity: Most statements perform one action per line, supporting readability. Reading flow: The overall progression from parsing to applying rules is logical, but misleading identifiers, method inconsistencies, and complex replacement handling repeatedly interrupt comprehension.
Run 2
Code Structure: Parsing, mapping, and replacement validation are separated into methods, with rule behavior encapsulated in a nested class. Nesting: Mostly shallow, though back-reference validation and rule formatting introduce moderate nesting. Clarity of intent: Severely weakened by unrelated names such as parseIndex, deliver, region, and primaryScore. Calling Rule.apply when only check exists, and using @Override on organize and sendMode, create confusing inconsistencies. Complex regexes and numbered capture groups also obscure intent. Code length: Reasonably compact overall, but verbose comments, repetitive formatting logic, and long exception expressions add reading burden. Action granularity: Generally one action per line, making individual operations easy to follow. Reading flow: The progression from parsing to rule application is logical, but misleading identifiers, inconsistent method names, and unexplained regex details repeatedly interrupt comprehension.
Run 3
Code Structure: Parsing, mapping, and replacement validation are separated into methods, with rules encapsulated in a nested class. Nesting: Mostly shallow, although back-reference validation has nested loops and conditions. Clarity of intent: Severely weakened by unrelated names such as parseIndex, client, primaryScore, and sendMode. The call to nonexistent Rule.apply (instead of check) and invalid @Override annotations on organize and sendMode further obscure intended relationships. Complex regexes and numbered capture groups require careful decoding. Code length: Reasonably bounded, but repetitive string construction and lengthy comments add bulk. Action granularity: Generally one action per line, making individual operations easy to scan. Reading flow: The progression from parsing to rule application is logical, but inconsistent naming, long expressions, and unexplained regex structure repeatedly interrupt comprehension.