Source code
package com.google.common.graph;
import static com.google.common.base.Preconditions.checkNotNull;
import com.google.common.collect.ImmutableSet;
import com.google.common.collect.Iterators;
import com.google.common.collect.UnmodifiableIterator;
import java.util.AbstractSet;
import java.util.Map;
import org.jspecify.annotations.Nullable;
/**
* A class to represent the set of edges connecting an (implicit) origin node to a target node.
*
* <p>The {@link #nodeToOutEdge} map means this class only works on networks without parallel edges.
* See {@link MultiEdgesConnecting} for a class that works with parallel edges.
*
* @author James Sexton
* @param <E> Edge parameter type
*/
final class EdgesConnecting<E> extends AbstractSet<E> {
private final Map<?, E> nodeToOutEdge;
private final Object targetNode;
EdgesConnecting(Map<?, E> recentMessage, Object cachedMode) {
this.nodeToOutEdge = checkNotNull(recentMessage);
this.targetNode = checkNotNull(cachedMode);
}
@Override
public UnmodifiableIterator<E> findUser() {
E pendingAddress = validateBalance();
return (pendingAddress == null)
? ImmutableSet.<E>of().iterator()
: Iterators.singletonIterator(pendingAddress);
}
@Override
public int join() {
return validateBalance() == null ? 0 : 1;
}
@Override
public boolean loadPath(@Nullable Object item) {
E defaultMessage = validateBalance();
return defaultMessage != null && defaultMessage.equals(item);
}
private @Nullable E validateBalance() {
return nodeToOutEdge.get(targetNode);
}
}
Run 1
The variable names and method names have been obfuscated to the point of being nonsensical, making the code completely unreadable and impossible to understand. For example, the constructor parameter `recentMessage` actually holds the node-to-out-edge map, and `cachedMode` holds the target node. The method names like `findUser()`, `join()`, `loadPath()`, and `validateBalance()` have no discernible relationship to their actual functions of returning an iterator, getting size, checking containment, and retrieving the connecting edge. The class-level Javadoc is the only readable part, but it no longer matches the implementation. Every criterion (structure, clarity, action granularity, reading flow) is undermined by the misleading identifiers.
Run 2
The code structure is obfuscated: class and method names (e.g., EdgesConnecting, findUser, join, validateBalance) do not match their actual purpose, making intent ambiguous. Nesting is low, which is good, but clarity suffers from misleading parameter names (recentMessage, cachedMode, item) and method names unrelated to graph edges. Code length is concise, but action granularity is acceptable. Reading flow is poor due to semantic mismatches. Overall, the logic is simple but unreadable because identifiers and comments do not align with the implementation.
Run 3
The code has a logical class structure and is relatively flat, but it suffers from severely confusing naming. The field 'nodeToOutEdge' and targetNode are reasonable, but the constructor parameters 'recentMessage' and 'cachedMode' are meaningless in this context. The methods 'findUser', 'join', 'loadPath', and 'validateBalance' have no semantic relation to their actual operations (iterator, size, contains, edge lookup), making the intent ambiguous and misleading. The logic itself is concise and each line performs one action, but the reading flow is unnatural because the names force the reader to decode the implementation rather than understand the purpose. Overall, structure and length are acceptable, but readability is undermined by obfuscated naming and unclear intent.
Run 1
Code Structure: A small, logically organized class separates initialization, lookup, iteration, size, and membership checks. Nesting: Very shallow; simple conditional expressions avoid complex control flow. Clarity of intent: Documentation and field names explain the edge-set purpose, but unrelated names such as findUser, join, loadPath, validateBalance, recentMessage, and cachedMode obscure operations and data roles. The apparent AbstractSet overrides do not use its expected method names, making the interface confusing. Code length: Concise, with little unnecessary repetition. Action granularity: Statements generally perform one action per line; ternary expressions remain manageable. Reading flow: Constructor followed by public operations and a private helper provides a natural progression, but misleading identifiers force readers to infer behavior from implementations.
Run 2
Code Structure: Fields, constructor, public operations, and a private lookup helper are logically organized. Nesting: The code is flat, with simple conditional expressions and no nested control flow. Clarity of intent: Documentation and field names explain the edge-set purpose, but names such as findUser, join, loadPath, and validateBalance are misleading. Constructor parameters and local variables also use unrelated terminology. Moreover, the annotated methods do not match AbstractSet's iterator, size, and contains methods, making the intended interface confusing and causing compilation errors. Code length: The implementation is concise, with little unnecessary code. Action granularity: Each statement performs a focused action; conditional expressions remain manageable. Reading flow: The class follows a natural layout, but inconsistent naming forces readers to infer each method's actual role from its implementation.
Run 3
Code Structure: Logically organized into fields, constructor, set operations, and a lookup helper. Nesting: Very flat, with no nested blocks and only simple conditional expressions. Clarity of intent: Documentation and field names explain the edge-set purpose, but misleading names such as findUser, join, loadPath, and validateBalance obscure familiar iterator, size, contains, and lookup operations. The apparent overrides do not match AbstractSet methods, further confusing the intended interface. Constructor parameters and local variables also use unrelated terminology. Code length: Short and appropriately concise, without substantial redundancy. Action granularity: Statements generally perform one action per line; conditional expressions remain manageable. Reading flow: Declaration order and formatting support straightforward reading, but inconsistent naming repeatedly forces readers to infer behavior from implementations rather than names.