Sample
int-324b82504f9f-I03
Replace method, parameter, and local names with length-matched, meaningful but unrelated names
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.987 | 0–1; higher is more readable |
| Scalabrino | 0.895 | 0–1; higher is more readable |
| Dorn | 0.342 | 0–1; higher is more readable |
| Mi | 0.039 | 0–1; higher is more readable |
| LLOC | 23 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 3 | 0–20; mean of three runs |
| GPT-6.1 Sol | 10.67 | 0–20; mean of three runs |
| BTTF | 0.58 | 0–1; higher is more readable |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Source linesThe number of non-empty source lines. | 168 | +67.2 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 1972.863 | −65.104 |
| 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.412 | −6.618 |
Intercept 8.87 + feature contributions = 4.347 (log-odds).
Score = sigmoid(4.347) = 0.987.
| Score | 0.895 |
|---|
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. | 169 | −4.947 |
| 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. | 148.994 | −2.646 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 85 | +2.203 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 167.927 | +1.937 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 148.982 | +1.599 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.022 | +0.733 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = -0.653 (log-odds).
Score = sigmoid(-0.653) = 0.342.
| Score | 0.039 |
|---|
| Score | 23 |
|---|
Run 1
This code is severely obfuscated. Method names like 'validateBalance', 'sendKey', 'validateAccount', and 'createBalance' bear no semantic relation to the interface's documented purpose (storing configuration). The parameter names are equally misleading ('nextCount', 'pendingKey', 'secureIndex'), making it impossible to infer intent despite extensive Javadoc. The interface appears to have been deliberately renamed, destroying clarity. Nesting is minimal, and the structure is logically organized at a high level, but the naming obliterates readability. The Javadoc comments contradict the methods, creating confusion rather than clarity. Action granularity is fine, but the reading flow is disorienting. This code fails to communicate its purpose effectively, making it nearly unreadable to any developer unfamiliar with the original method names and parameter semantics.
Run 2
The code appears to be an obfuscated or deliberately corrupted version of the Kafka Connect ConfigBackingStore interface. While the overall structure follows a standard Java interface pattern, the implementation is severely compromised. Method names (validateBalance, validateAddress, validateStatus, etc.) do not match their documented purposes or parameter types (e.g., 'findNode' takes 'reference' but documentation says 'connector'). Parameter names are misleading ('nextCount', 'pendingKey', 'secureIndex' for connector/targetState). Javadoc comments describe correct functionality but do not align with method signatures. This creates extreme confusion between intent and implementation. Reading flow is broken by inconsistent naming across methods and parameters. The code is practically unreadable and unmaintainable, despite having proper formatting and structure on the surface.
Run 3
The code has major readability issues. While it retains an interface structure, the method names and parameter names are nonsensical (e.g., 'validateBalance', 'sendKey', 'refreshAccount', 'localUser', 'pendingKey') and do not reflect the operations described in the Javadoc comments, making the purpose ambiguous. The Javadoc comments themselves describe standard configuration store operations, but the identifiers are completely disconnected from those descriptions, creating confusion. Nesting is minimal and the structure is flat, but clarity of intent is severely compromised. Method parameters are poorly named and do not communicate their meaning. The code is not overly long, but the naming makes it effectively unreadable. Despite having one action per method, the reading flow is disrupted by the mismatch between comments and actual code identifiers.
Run 1
Code Structure: Logically organized as a storage interface with a nested update-listener interface and consistent method separation. Nesting: Minimal, with only one nested interface and an empty default method. Clarity of intent: Severely weakened by misleading method and parameter names such as validateBalance and secureIndex. Documentation explains intended operations, but @param names do not match signatures, and the snapshot() reference does not match evaluate(). Undocumented check() and read() are ambiguous. Code length: Method declarations are concise; extensive documentation is mostly useful, though some lines are overly long. Action granularity: Each declaration occupies its own line, with no bundled operations. Reading flow: Consistent formatting supports scanning, but readers must repeatedly reconcile documentation with unrelated identifiers, disrupting comprehension.
Run 2
1. Code Structure: Logically organized as a storage interface with a nested update-listener interface and consistently separated declarations. 2. Nesting: Very shallow, with no complex control flow. 3. Clarity of intent: Severely weakened by misleading method and parameter names, such as validateBalance for updating configurations. Javadoc parameter names do not match signatures, the snapshot() reference points to an absent method, and check() and read() lack explanations. Documentation conveys intended behavior but conflicts with the API. 4. Code length: Appropriate for the interface's scope, although lengthy comments and long lines reduce scanability. 5. Action granularity: Each declaration occupies its own line; no bundled actions. 6. Reading flow: Consistent formatting and operation-by-operation documentation provide a natural progression, but readers must repeatedly reconcile descriptions with unrelated identifiers.
Run 3
Code Structure: The interface is logically organized, with store operations followed by a nested listener interface. Nesting: Minimal and easy to follow; there is no deeply nested control flow. Clarity of intent: Severely weakened by misleading method and parameter names, such as validateBalance for updating connector configuration. Documentation helps explain operations, but @param names do not match signatures, the snapshot() reference is missing, and check()/read() lack explanations. Code length: Reasonable for the API's scope, although lengthy comments compensate for poor naming. Action granularity: Each declaration occupies its own line, with no bundled actions. Reading flow: Consistent formatting and spacing make scanning straightforward, but repeated generic names and contradictions between signatures and documentation force readers to reinterpret each operation.