Sample
int-77dcb9862314-I02
Shorten method, parameter, and local names without collisions
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.791 | 0–1; higher is more readable |
| Dorn | 0.04 | 0–1; higher is more readable |
| Mi | 0.131 | 0–1; higher is more readable |
| LLOC | 58 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 3.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 13 | 0–20; mean of three runs |
| BTTF | 0.646 | 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. | 5132.218 | −169.363 |
| Source linesThe number of non-empty source lines. | 291 | +116.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.784 | −7.175 |
Intercept 8.87 + feature contributions = -51.269 (log-odds).
Score = sigmoid(-51.269) = 0.
| Score | 0.791 |
|---|
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. | 292 | −9.302 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 162 | +4.866 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 290.842 | +3.656 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 162 | −3.297 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 98.253 | +0.781 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.034 | +0.615 |
| 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. | 99.955 | −0.569 |
Intercept 0.07 + feature contributions = -3.18 (log-odds).
Score = sigmoid(-3.18) = 0.04.
| Score | 0.131 |
|---|
| Score | 58 |
|---|
Run 1
The code is largely unreadable due to heavily obfuscated identifiers. Methods like 'sta', 'com', 'cla', 'res', and 'compare2' are meaningless and obscure the intent of the fluent API. Variable names like 'lef1' through 'lef25' and 'rig1' through 'rig25' make parameter roles indistinguishable and imply machine-generated renaming. The logical structure, though trying to be modular via inheritance, is destroyed by these names; the distinction between ACTIVE and InactiveComparisonChain becomes difficult to follow. While the original code likely had descriptive names like start(), compare(), classify(), and result(), this version is extremely ambiguous. Nesting is acceptable, but clarity of intent is severely compromised. The extensive documentation describes a clear API, but the implementation fails to match it, creating a major disconnect for a reader. Overall, the code requires constant mental mapping to understand basic operations.
Run 2
This code has severe readability problems. The method names are abbreviated to near meaninglessness: 'sta' instead of 'start', 'com' instead of 'compare', 'res' instead of 'result', 'cla' instead of 'classify'. Method parameters and local variables use suffixes like lef1, rig1, lef2, rig2, lef17, etc., making it impossible to understand which variable belongs to which context at a glance. The boolean comparison logic is confusing—one method compares reversed, another doesn't, and an abstract method 'com' is combined with a deprecated concrete method 'com' for Boolean objects, creating ambiguity. The anonymous inner class combined with a private static class creates structural noise, and the documentation is extensive but dense. Nesting is moderate but mixed with the poor naming, making the flow hard to follow. Overall the code violates almost all readability criteria.
Run 3
The code is severely obfuscated and unreadable. Method and parameter names are meaningless ('sta', 'com', 'cla', 'res', 'lef1', 'rig1', 'lef2', etc.), completely obscuring the intent. The logical structure is tangled due to the extreme renaming, making it difficult to follow the comparison chain flow. Although the nesting is flat and the class structure is present, clarity of intent is destroyed. The code is also unnecessarily long because each primitive overload is written out with cryptic names, and the Javadoc references methods that don't exist ('compareFalseFirst', 'compareTrueFirst'). Action granularity is mostly one action per line, but the unreadable identifiers negate any benefit. Reading flow is completely unnatural.
Run 1
Code Structure: Active and inactive comparison states are logically separated, with consistently grouped overloads. Nesting: Mostly shallow; the anonymous implementation and nested ternary add modest complexity. Clarity of intent: Documentation explains the comparison-chain behavior well, but abbreviated names such as sta, com, cla, and res, numbered parameters, and compare versus compare2 obscure meaning. Examples and documentation references use names absent from the actual API, creating confusion. Code length: Numerous overloads and repeated inactive implementations increase length, although much of this supports the API; extensive documentation further slows scanning. Action granularity: Methods generally perform one clear action per line, with short bodies. Reading flow: Consistent formatting and predictable method ordering help, but readers must move between implementations and abstract declarations, while inconsistent naming and stale documentation interrupt comprehension.
Run 2
Code Structure: Active and inactive comparison states are logically separated, with consistently grouped overloads. Nesting: Mostly shallow; the anonymous class and nested ternary add modest complexity. Clarity of intent: Extensive documentation explains behavior, but abbreviated names such as sta, com, cla, and res, numbered parameters, and ambiguous compare/compare2 names obscure meaning. Documentation examples and links reference names absent from the actual API, further confusing readers. Code length: Individual methods are concise, but repeated overloads and lengthy documentation make the class cumbersome to scan, although much repetition supports the API. Action granularity: Statements generally perform one action per line; comparison and state classification are compactly combined without excessive density. Reading flow: Consistent formatting and method ordering help, but readers must move between implementations and abstract declarations, while naming inconsistencies interrupt otherwise predictable flow.
Run 3
Code Structure: Active and inactive comparison states are logically separated, with consistently grouped overloads. Nesting: Mostly shallow; the anonymous class and nested ternary add modest complexity. Clarity of intent: Documentation explains the design well, but abbreviated names such as sta, com, cla, and res, numbered parameters, and compare versus compare2 obscure meaning. Examples, links, and the inline replacement reference names absent from the actual API, creating confusion. Code length: Individual methods are concise, but repeated overloads and extensive documentation make the class lengthy to scan. Action granularity: Most lines contain one clear operation; the nested ternary compresses multiple decisions. Reading flow: Consistent formatting and parallel implementations help, but placing public declarations after implementation details requires backtracking, and mismatched documentation interrupts comprehension.