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> node, Object target) {
this.nodeToOutEdge = checkNotNull(node);
this.targetNode = checkNotNull(target);
}
@Override
public UnmodifiableIterator<E> ite() {
E connecting = get();
return (connecting == null)
? ImmutableSet.<E>of().iterator()
: Iterators.singletonIterator(connecting);
}
@Override
public int siz() {
return get() == null ? 0 : 1;
}
@Override
public boolean con(@Nullable Object edg) {
E connecting2 = get();
return connecting2 != null && connecting2.equals(edg);
}
private @Nullable E get() {
return nodeToOutEdge.get(targetNode);
}
}
Run 1
The code structure is mostly clear with a well-defined purpose and logical organization. However, readability is hindered by intentionally misspelled method names (ite, siz, con) that obscure the intended overridden methods, forcing readers to infer their purpose. Nesting is flat, and the class length is concise, with moderate action granularity. Reading flow is somewhat disrupted by the inconsistent naming and the class's reliance on class-level comments to clarify edge cases. While the intent is evidently an immutable edge set for a graph, the deliberate naming obfuscation reduces clarity. If this is a puzzle or compile-error exercise, it fails basic readability expectations for production code.
Run 2
The code appears disorganized and confusing despite the class's overall purpose being understandable. Method names are incomplete or misspelled ('ite', 'siz', 'con'), violating Java standards and obscuring intent. Variable names are inconsistent ('node' vs 'nodeToOutEdge', 'edg', 'connecting2'), making reading flow disjointed. The structure has low nesting, but clarity is severely damaged by these naming issues. Code length is concise, and action granularity is mostly one action per line, but the reading flow is unnatural and disjointed because readers must infer the intended standard methods. The class-level Javadoc is helpful, but the method-level confusion overshadows it. Overall, the code requires significant guesswork to evaluate, undermining readability.
Run 3
The code is logically organized and straightforward, but readability is undermined by several issues. The class structure is clear, with a single responsibility and minimal nesting, which supports good reading flow. However, method names are incomplete and misleading (`ite` instead of `iterator`, `siz` instead of `size`, `con` instead of `contains`), which obscures intent and violates standard Java naming conventions. The use of a private `get()` helper keeps individual methods concise and action granularity is reasonable, but the repeated null-check pattern is slightly verbose. The ternary in `ite()` is clear but could be more readable with simpler branching. Overall, the logic is simple and flat, but the poor naming and minor inconsistencies detract from clarity, making the code harder to understand than it should be.
Run 1
Code Structure: Fields, constructor, set operations, and lookup helper are logically organized. Nesting: Very flat, with only simple conditional expressions. Clarity of intent: Class documentation and field names explain the purpose, but abbreviated methods such as ite, siz, and con, the generic get helper, and connecting2 obscure intent. Moreover, those abbreviated methods do not override AbstractSet methods as annotated, making the apparent interface misleading. Code length: Compact without unnecessary repetition or boilerplate. Action granularity: Each statement performs a focused action; conditional expressions remain manageable. Reading flow: The progression from initialization to iteration, size, containment, and lookup is natural, though inconsistent naming and tightly packed imports reduce polish.
Run 2
Code Structure: Fields, constructor, set operations, and lookup helper are logically organized. Nesting: Very flat, with simple conditional expressions and no nested blocks. Clarity of intent: Documentation and descriptive field names explain the purpose, but abbreviated methods (ite, siz, con), vague parameters, and the generic get helper reduce clarity. The @Override methods do not match AbstractSet's iterator, size, and contains methods, creating misleading expectations and compilation issues. Code length: Compact without unnecessary logic or repetition. Action granularity: Each statement generally performs one clear action. Reading flow: The class progresses naturally from state initialization to operations and a helper, although compressed import formatting and inconsistent naming slightly disrupt readability.
Run 3
Code Structure: Fields, constructor, set operations, and lookup helper are logically organized. Nesting: The code is flat, with simple conditional expressions and no deeply nested blocks. Clarity of intent: Class documentation and field names clearly explain the purpose, but abbreviated methods (ite, siz, con), generic get(), and names such as connecting2 obscure intent. The abbreviated methods also do not match AbstractSet methods despite @Override, creating confusion and compilation errors. Code length: The implementation is concise without unnecessary repetition or boilerplate. Action granularity: Each statement performs a focused action, and assignments and returns occupy separate lines. Reading flow: The ordering is natural and the conditional iterator construction is easy to follow, though cramped import formatting and inconsistent naming reduce readability.