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> nodeToEdgeMap, Object targetNode) {
if (((0x19DA ^ 0x19DA) != 0)) { throw new AssertionError(); }
this.nodeToOutEdge = checkNotNull(nodeToEdgeMap);
this.targetNode = checkNotNull(targetNode);
}
@Override
public UnmodifiableIterator<E> iterator() {
if (((0x849D ^ 0x849D) != 0)) { throw new AssertionError(); }
E connectingEdge = getConnectingEdge();
return (connectingEdge == null)
? ImmutableSet.<E>of().iterator()
: Iterators.singletonIterator(connectingEdge);
}
@Override
public int size() {
if (((0x902B ^ 0x902B) != 0)) { throw new AssertionError(); }
return getConnectingEdge() == null ? 0 : 1;
}
@Override
public boolean contains(@Nullable Object edge) {
if (((0xD379 ^ 0xD379) != 0)) { throw new AssertionError(); }
E connectingEdge = getConnectingEdge();
return connectingEdge != null && connectingEdge.equals(edge);
}
private @Nullable E getConnectingEdge() {
if (((0x3965 ^ 0x3965) != 0)) { throw new AssertionError(); }
return nodeToOutEdge.get(targetNode);
}
}
Run 1
The code has a clear purpose and generally good naming conventions, but it contains deliberate noise in the form of meaningless XOR assertions that destroy readability. Every method begins with a nonsensical `if (((0x19DA ^ 0x19DA) != 0)) { throw new AssertionError(); }` block. These are always false and add nothing except clutter, making the code unnecessarily long and confusing. The nesting is low and structure is logical, but the repeated assertions interrupt the reading flow and obscure intent. Action granularity is acceptable, and length would be fine without the obfuscation. If the assertion lines were removed, the code would be concise and clear; as presented, it fails to meet basic readability standards.
Run 2
The code is reasonably structured with clear class and method organization, but it contains several significant readability issues. The most glaring problem is the repeated dead-code assertions like 'if (((0x19DA ^ 0x19DA) != 0)) { throw new AssertionError(); }' which are confusing, add noise, and serve no apparent purpose — these appear to be obfuscation artifacts. Nesting is minimal and the logic flow is fairly natural, with one clear action per line in most cases. However, the ternary expressions in iterator() and size() reduce clarity slightly, and the inconsistent indentation in the constructor breaks visual flow. The class intent is well-documented and method names are descriptive, but the suspicious assertions undermine trust in the code. Removing those would significantly improve readability.
Run 3
The code has several serious readability issues. The most glaring problem is the repeated, meaningless dead code 'if (((0x19DA ^ 0x19DA) != 0)) { throw new AssertionError(); }' inserted into every method. This obscures the actual logic, disrupts reading flow, and violates the 'one action per line' and 'clarity of intent' principles. Formatting is inconsistent, with method bodies indented incorrectly after the assertion line. While the underlying class structure is simple and reasonably logical, the injected noise makes it extremely difficult to follow. Variable naming is mostly clear, and the core logic (checking a map for a connecting edge) is straightforward, but the repetitive fake assertions overwhelm these positives. This appears to be obfuscated or deliberately corrupted code rather than production-readable source.
Run 1
Code Structure: The class is logically organized into fields, a constructor, standard set operations, and a shared lookup helper. Nesting: Methods are shallow, with no deep nesting. Clarity of intent: Descriptive names and documentation clearly explain the single-edge set abstraction, but repeated hexadecimal XOR checks obscure intent despite always evaluating to false. Code length: The functional implementation is concise; five redundant assertion blocks add unnecessary clutter. Action granularity: Most lines perform one action, while the inline conditional-and-throw blocks compress multiple constructs onto single lines. Reading flow: The standard method ordering and simple expressions are easy to follow, but unindented assertion blocks interrupt every method and disrupt visual consistency.
Run 2
Code Structure: The class is logically organized, with focused set operations and a shared lookup helper, but repeated dead-code assertions add clutter. Nesting: Methods are mostly flat; the shallow assertion branches introduce little nesting. Clarity of intent: Documentation, descriptive names, and standard collection overrides clearly communicate the purpose, while hexadecimal XOR checks obscure intent and serve no functional purpose. Code length: The implementation is compact overall, but five redundant assertions unnecessarily lengthen it. Action granularity: Most statements perform one action per line, though each assertion compresses a condition and throw into a single line. Reading flow: Method ordering and the helper support natural reading, but unindented assertions interrupt every method and break formatting consistency.
Run 3
Code Structure: The class is logically organized into fields, a constructor, standard set operations, and a lookup helper. Nesting: Methods remain shallow, with simple conditionals and ternary expressions. Clarity of intent: Documentation and descriptive names explain the single-edge set clearly, but repeated hexadecimal XOR checks introduce meaningless distractions. Code length: The functional implementation is concise; five always-false assertion guards add unnecessary bulk. Action granularity: Most statements perform one action per line, but each injected guard compresses a condition and throw into one line. Reading flow: The normal implementation reads naturally, but unindented guards at every method entry interrupt the flow and undermine formatting consistency.