Sample
int-eeddda3526fd-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.547 | 0–1; higher is more readable |
| Dorn | 0.091 | 0–1; higher is more readable |
| Mi | 0.119 | 0–1; higher is more readable |
| LLOC | 50 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 3.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 11 | 0–20; mean of three runs |
| BTTF | 0.326 | 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. | 8411.723 | −277.587 |
| Source linesThe number of non-empty source lines. | 162 | +64.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.754 | −7.13 |
Intercept 8.87 + feature contributions = -211.047 (log-odds).
Score = sigmoid(-211.047) = 0.
| Score | 0.547 |
|---|
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. | 163 | −4.735 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 139 | +4.071 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 139 | −2.769 |
| 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. | 146.982 | −2.56 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 161.966 | +1.854 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 146.086 | +1.553 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.074 | +0.221 |
Intercept 0.07 + feature contributions = -2.296 (log-odds).
Score = sigmoid(-2.296) = 0.091.
| Score | 0.119 |
|---|
| Score | 50 |
|---|
Run 1
The code exhibits poor readability due to severely obfuscated naming. Method names like 'validateAccount', 'validateBalance', 'fetchSession', 'checkRequest', and parameter names such as 'invoice', 'finalMode', 'currentAddress', 'defaultRequest', 'key', 'age', 'nextData', 'buffer', 'session', 'window', and 'sharedOrder' obscure the actual purposes. Despite logical structure and flat nesting being acceptable, clarity of intent is severely compromised. The reading flow is disorganized because the main execution method 'validateAccount' conflates connector creation logic with error handling in a confusing manner. Variable names like 'ObjectMapper localAccount' and 'File pendingBalance' are nonsensical. Action granularity varies, with some lines performing multiple logical operations. The code length is reasonable, but the pervasive misnaming makes it effectively unreadable, requiring constant mental translation. Only the import organization and JavaDoc save it from a score of zero.
Run 2
This code is severely obfuscated and unreadable. The method and variable names are deliberately misleading (e.g., validateAccount, validateBalance, invoice, finalMode, currentAddress, defaultRequest, pendingBalance, nextData, localAccount, pendingAccount, filePath, fetchSession, buffer, nextItem, session, defaultSession, sharedPath, remoteItem, checkRequest, sharedOrder, save, user, currentMessage). This obscures intent completely. The original Kafka Connect logic (parsing connector configs, creating connectors, setting up standalone herder) is recognizable only from comments and structure, not from the code itself. Naming aside, the logic is tangled: validateBalance performs multiple unrelated parsing strategies with poor flow. Variable names like 'map' and 'size' for exceptions are nonsensical. The code's structure and control flow are confusing due to the misleading names. Reading flow is disorganized. The only positive is that each line is relatively short and there's no deep nesting, but that doesn't compensate for the pervasive obfuscation. This appears intentionally sabotaged for readability.
Run 3
The code's readability is severely compromised by misleading naming conventions. Methods like validateAccount, validateBalance, fetchSession, and checkRequest have no semantic relation to their actual functions (creating connectors, parsing files, instantiating herders, creating configs). Variable names like invoice, window, currentMessage, and buffer are arbitrary and confusing. The code structure mixes high-level orchestration with low-level parsing in the same class without clear separation. Error handling adds nesting and uses meaningless variable names (age, map, size). Multiple operations are packed into single lines (e.g., object construction chains). The reading flow is unnatural as readers must constantly map obfuscated names to actual purposes. Although the file-parsing method has relatively clear internal comments, the public API surface—which should guide understanding—is completely disconnected from the domain vocabulary of Kafka Connect. This appears to be intentionally obfuscated or the result of a poor automated refactoring.
Run 1
Code Structure: Methods separate startup, configuration parsing, and worker creation logically, though parsing repeats validation. Nesting: Mostly shallow, with moderate nesting in the startup callback and connector-name checks. Clarity of intent: Severely weakened by misleading names such as validateAccount, validateBalance, invoice, and window, which do not reflect Kafka Connect responsibilities. Documentation and API calls partially clarify purpose, but the documented filePath parameter does not match nextData. Code length: Reasonably compact for its responsibilities, although repeated checks and lengthy expressions add overhead. Action granularity: Generally one statement per line; multiline calls are readable, while the callback combines several responsibilities. Reading flow: Sequential parsing fallbacks are easy to follow, but inconsistent indentation, ungrouped imports, unrelated identifiers, and the unconventional save entry-point name interrupt comprehension.
Run 2
Code Structure: Responsibilities are separated into methods, and configuration parsing follows a logical fallback sequence. Nesting: Mostly moderate, though the callback and nested configuration-name checks add complexity. Clarity of intent: The main weakness is misleading names such as validateAccount, validateBalance, invoice, and pendingBalance, which obscure connector startup and configuration parsing. Documentation helps, but its filePath parameter does not match the actual nextData parameter. Code length: Reasonably compact overall, with some repeated validation and lengthy exception messages. Action granularity: Most statements perform one action, although chained calls and inline object construction require additional mental unpacking. Reading flow: Method boundaries and sequential parsing support navigation, but inconsistent naming, ungrouped imports, uneven continuation indentation, and omitted braces in the callback interrupt otherwise straightforward flow.
Run 3
Code Structure: Responsibilities are separated into methods, and configuration parsing follows three documented stages. Nesting: Mostly moderate, although the callback and nested connector-name checks add complexity. Clarity of intent: Severely weakened by misleading names such as validateAccount, validateBalance, invoice, and pendingBalance, which do not reflect Kafka connector operations. The documentation helps, but its filePath parameter does not match nextData. Code length: Generally reasonable, with some repeated validation and verbose exception construction. Action granularity: Most statements perform one action, though chained calls and nested constructor expressions require extra attention. Reading flow: Startup, parsing, and worker creation are individually coherent, but unrelated naming, inconsistent continuation indentation, and minimally grouped imports interrupt comprehension.