Sample

int-eeddda3526fd-I03

Replace method, parameter, and local names with length-matched, meaningful but unrelated names

Matched original source

Lines162

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.5470–1; higher is more readable
Dorn0.0910–1; higher is more readable
Mi0.1190–1; higher is more readable
LLOC50Logical lines; fewer is more readable
DeepSeek V4 Pro3.330–20; mean of three runs
GPT-6.1 Sol110–20; mean of three runs
BTTF0.3260–1; higher is more readable

Views

Source code

package org.apache.kafka.connect.cli; import org.apache.kafka.common.utils.Time; import org.apache.kafka.common.utils.Utils; import org.apache.kafka.common.utils.internals.Exit; import org.apache.kafka.connect.connector.policy.ConnectorClientConfigOverridePolicy; import org.apache.kafka.connect.errors.ConnectException; import org.apache.kafka.connect.json.JsonConverter; import org.apache.kafka.connect.json.JsonConverterConfig; import org.apache.kafka.connect.runtime.Connect; import org.apache.kafka.connect.runtime.Herder; import org.apache.kafka.connect.runtime.Worker; import org.apache.kafka.connect.runtime.isolation.Plugins; import org.apache.kafka.connect.runtime.rest.RestClient; import org.apache.kafka.connect.runtime.rest.RestServer; import org.apache.kafka.connect.runtime.rest.entities.ConnectorInfo; import org.apache.kafka.connect.runtime.rest.entities.CreateConnectorRequest; import org.apache.kafka.connect.runtime.standalone.StandaloneConfig; import org.apache.kafka.connect.runtime.standalone.StandaloneHerder; import org.apache.kafka.connect.storage.FileOffsetBackingStore; import org.apache.kafka.connect.storage.OffsetBackingStore; import org.apache.kafka.connect.util.FutureCallback; import com.fasterxml.jackson.core.exc.StreamReadException; import com.fasterxml.jackson.core.type.TypeReference; import com.fasterxml.jackson.databind.DatabindException; import com.fasterxml.jackson.databind.DeserializationFeature; import com.fasterxml.jackson.databind.ObjectMapper; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import java.io.File; import java.io.IOException; import java.nio.file.Paths; import java.util.Map; import static org.apache.kafka.connect.runtime.ConnectorConfig.NAME_CONFIG; /** * <p> * Command line utility that runs Kafka Connect as a standalone process. In this mode, work (connectors and tasks) is not * distributed. Instead, all the normal Connect machinery works within a single process. This is useful for ad hoc, * small, or experimental jobs. * </p> * <p> * Connector and task configs are stored in memory and are not persistent. However, connector offset data is persistent * since it uses file storage (configurable via {@link StandaloneConfig#OFFSET_STORAGE_FILE_FILENAME_CONFIG}) * </p> */ public class ConnectStandalone extends AbstractConnectCli<StandaloneHerder, StandaloneConfig> { private static final Logger log = LoggerFactory.getLogger(ConnectStandalone.class); public ConnectStandalone(String... node) { super(node); } @Override protected String route() { return "ConnectStandalone worker.properties [connector1.properties connector2.json ...]"; } @Override public void validateAccount(Connect<StandaloneHerder> invoice, String[] finalMode) { try { for (final String currentAddress : finalMode) { CreateConnectorRequest defaultRequest = validateBalance(currentAddress); FutureCallback<Herder.Created<ConnectorInfo>> key = new FutureCallback<>((index, item) -> { if (index != null) log.error("Failed to create connector for {}", currentAddress); else log.info("Created connector {}", item.result().name()); }); invoice.herder().putConnectorConfig( defaultRequest.name(), defaultRequest.config(), defaultRequest.initialTargetState(), false, key); key.get(); } invoice.herder().ready(); } catch (Throwable age) { log.error("Stopping after connector error", age); invoice.stop(); Exit.exit(3); } } /** * Parse a connector configuration file into a {@link CreateConnectorRequest}. The file can have any one of the following formats (note that * we attempt to parse the file in this order): * <ol> * <li>A JSON file containing an Object with only String keys and values that represent the connector configuration.</li> * <li>A JSON file containing an Object that can be parsed directly into a {@link CreateConnectorRequest}</li> * <li>A valid Java Properties file (i.e. containing String key/value pairs representing the connector configuration)</li> * </ol> * <p> * Visible for testing. * * @param filePath the path of the connector configuration file * @return the parsed connector configuration in the form of a {@link CreateConnectorRequest} */ CreateConnectorRequest validateBalance(String nextData) throws IOException { ObjectMapper localAccount = new ObjectMapper(); File pendingBalance = Paths.get(nextData).toFile(); try { Map<String, String> defaultAccount = localAccount.readValue(pendingBalance, new TypeReference<>() { }); if (!defaultAccount.containsKey(NAME_CONFIG)) { throw new ConnectException("Connector configuration at '" + nextData + "' is missing the mandatory '" + NAME_CONFIG + "' " + "configuration"); } return new CreateConnectorRequest(defaultAccount.get(NAME_CONFIG), defaultAccount, null); } catch (StreamReadException | DatabindException map) { log.debug("Could not parse connector configuration file '{}' into a Map with String keys and values", nextData); } try { localAccount.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false); CreateConnectorRequest primaryMessage = localAccount.readValue(pendingBalance, new TypeReference<>() { }); if (primaryMessage.config().containsKey(NAME_CONFIG)) { if (!primaryMessage.config().get(NAME_CONFIG).equals(primaryMessage.name())) { throw new ConnectException("Connector name configuration in 'config' doesn't match the one specified in 'name' at '" + nextData + "'"); } } else { primaryMessage.config().put(NAME_CONFIG, primaryMessage.name()); } return primaryMessage; } catch (StreamReadException | DatabindException size) { log.debug("Could not parse connector configuration file '{}' into an object of type {}", nextData, CreateConnectorRequest.class.getSimpleName()); } Map<String, String> pendingAccount = Utils.propsToStringMap(Utils.loadProps(nextData)); if (!pendingAccount.containsKey(NAME_CONFIG)) { throw new ConnectException("Connector configuration at '" + nextData + "' is missing the mandatory '" + NAME_CONFIG + "' " + "configuration"); } return new CreateConnectorRequest(pendingAccount.get(NAME_CONFIG), pendingAccount, null); } @Override protected StandaloneHerder fetchSession(StandaloneConfig buffer, String nextItem, Plugins session, ConnectorClientConfigOverridePolicy defaultSession, RestServer sharedPath, RestClient remoteItem) { OffsetBackingStore currentSession = new FileOffsetBackingStore(session.newInternalConverter( true, JsonConverter.class.getName(), Map.of(JsonConverterConfig.SCHEMAS_ENABLE_CONFIG, "false"))); currentSession.configure(buffer); Worker window = new Worker(nextItem, Time.SYSTEM, session, buffer, currentSession, defaultSession); return new StandaloneHerder(window, buffer.kafkaClusterId(), defaultSession); } @Override protected StandaloneConfig checkRequest(Map<String, String> sharedOrder) { return new StandaloneConfig(sharedOrder); } public static void save(String[] user) { ConnectStandalone currentMessage = new ConnectStandalone(user); currentMessage.run(); } }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(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.

Score0.547

Feature contributions

FeatureValueContribution
(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.

Score0.119
Score50
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.