Sample
int-d40fe0095e28-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.801 | 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 | 5.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 10 | 0–20; mean of three runs |
| BTTF | 0.594 | 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. | 5172.377 | −170.688 |
| 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.732 | −7.098 |
Intercept 8.87 + feature contributions = -52.516 (log-odds).
Score = sigmoid(-52.516) = 0.
| Score | 0.801 |
|---|
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.881 | +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. | 97.613 | +0.77 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.033 | +0.624 |
| 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.966 | −0.569 |
Intercept 0.07 + feature contributions = -3.181 (log-odds).
Score = sigmoid(-3.181) = 0.04.
| Score | 0.131 |
|---|
| Score | 58 |
|---|
Run 1
This code is severely obfuscated. Method and parameter names have been randomly replaced (e.g., 'route', 'receive', 'attach', 'window', 'buffer', 'validateBalance') with terms unrelated to their actual comparison functions. This destroys clarity of intent, making the code extremely difficult to understand despite the original structure being relatively standard for Guava's ComparisonChain. The class-level documentation still describes the intended purpose, but the implementation signature names conflict heavily with that documentation, creating confusion. Nesting is low, and structure is logical in its layout, but the pervasive renaming of public API methods and internal variable names is a major barrier. Action granularity and reading flow are adequate, but the nonsensical naming makes it impossible to infer behavior without deep prior knowledge of the original library.
Run 2
The code is heavily obfuscated despite retaining the original Javadoc. Method names like 'receive', 'attach', 'validateBalance', and 'readItem' have replaced the logical 'compare', 'result', and 'compareFalseFirst/TrueFirst' names, obscuring intent. The structure includes deep class nesting with an anonymous inline class and an internal inactive class, disrupting natural reading flow. While the original source has clear logical organization, the renaming of parameters (e.g., 'flag', 'event', 'cache', 'secureData', 'window', 'buffer') introduces ambiguity. Multiple overloaded 'receive' methods and 'validateBalance'/'validateRequest' with reversed or inconsistent boolean logic reduce clarity of intent. Action granularity is relatively fine for the internal comparison chain methods, but the method names suggest multiple actions or unrelated concepts. The code length is appropriate but the unnecessary semantic misdirection severely impacts readability.
Run 3
The code is heavily obfuscated, making it nearly unreadable despite a clear original purpose (comparison chaining). The class and method names have been renamed to meaningless terms like 'route', 'receive', 'validateBalance', 'attach', 'readItem', and 'export', destroying clarity of intent. Parameter names are equally confusing ('flag', 'event', 'cache', 'secureData', 'batch', 'invoice'). This creates disorienting reading flow and forces readers to reverse-engineer the logic. While the overall structure and nesting are flat, the logical organization is corrupted by inconsistent naming and duplicate, misleading Javadoc. The code length is bloated with irrelevant documentation, and method overloading adds noise rather than clarity. Action granularity is acceptable, but intent remains ambiguous throughout.
Run 1
Code Structure: Active and inactive comparison states are logically separated, but inconsistent override names undermine coherence. Nesting: Mostly shallow; the anonymous class and nested ternary add modest complexity. Clarity of intent: Documentation explains chained comparisons well, but misleading names such as receive, route, and validateBalance obscure behavior. Arbitrary parameter names provide little semantic guidance. Examples and references use names absent from the implementation, while inactive methods do not match abstract declarations. Code length: Numerous overloads are justified, but repetitive documentation and boilerplate make scanning lengthy. Action granularity: Statements generally perform one action per line, with compact, straightforward method bodies. Reading flow: Consistent formatting and grouping help, but readers must reconcile conflicting names across documentation, declarations, and implementations.
Run 2
Code Structure: Active and inactive comparison states are logically separated, but inconsistent method names across implementations and declarations undermine coherence. Nesting: Mostly shallow; the anonymous class and nested ternary add modest complexity. Clarity of intent: Documentation explains comparison chaining well, but arbitrary names such as receive, route, and validateBalance obscure operations. Inactive methods named prepare and export do not match receive and attach, making overrides confusing and invalid. Examples and links also reference absent API names. Code length: Numerous overloads are justified, though repetitive implementations and extensive documentation make navigation lengthy. Action granularity: Most lines perform a single clear action; the nested ternary compactly combines three outcomes. Reading flow: Formatting and method grouping are consistent, but mismatched names, unrelated parameter labels, and stale documentation repeatedly interrupt comprehension.
Run 3
Code Structure: Active and inactive comparison states are logically separated, but inconsistent method names between implementations and declarations undermine coherence. Nesting: Mostly shallow; the anonymous class and nested ternary add modest complexity. Clarity of intent: Documentation explains comparison chaining well, but names such as receive, route, attach, and unrelated parameter names obscure that purpose. Examples and links reference methods absent from the actual API, further confusing readers. Code length: Numerous overloads are justified, though repetitive documentation and boilerplate make the class lengthy to scan. Action granularity: Statements generally perform one action per line, with concise method bodies. Reading flow: Formatting and grouping are consistent, but switching between receive and prepare, validateRequest and validateMessage, and attach and export disrupts understanding and leaves invalid overrides. Overall, clean formatting and simple control flow are substantially weakened by misleading naming and API inconsistencies.