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> a, Object b) {
this.nodeToOutEdge = checkNotNull(a);
this.targetNode = checkNotNull(b);
}
@Override
public UnmodifiableIterator<E> a() {
E c = d();
return (c == null)
? ImmutableSet.<E>of().iterator()
: Iterators.singletonIterator(c);
}
@Override
public int b() {
return d() == null ? 0 : 1;
}
@Override
public boolean c(@Nullable Object d) {
E e = d();
return e != null && e.equals(d);
}
private @Nullable E d() {
return nodeToOutEdge.get(targetNode);
}
}
Run 1
The code suffers from heavily obfuscated method names (a(), b(), c(), d()) that obscure intent and make the logic hard to follow. While the structure is logically organized as a simple Set implementation, the unclear naming forces readers to infer behavior from implementation details rather than method semantics. Nesting is minimal, which is good, and lines are generally short with one action per line. However, the ternary expressions in a() and b() add minor cognitive overhead, and the reading flow is broken by non-descriptive names. The class javadoc is helpful but does not compensate for poor method naming. Overall, the code is functionally concise but poorly readable due to ambiguous identifiers.
Run 2
The code structure is mostly straightforward with a clear class purpose, but it is severely undermined by single-letter method names (a(), b(), c(), d()) that obscure intent. This causes significant ambiguity and poor readability despite the otherwise simple logic. Nesting is minimal, which is good, but the method naming and parameter names (a, b, c, d) break clarity of intent and reading flow. Code length is very concise, but the lack of descriptive naming makes it feel obfuscated rather than elegant. Action granularity is mostly fine, with one meaningful operation per line, but the unexplained names prevent natural comprehension. The iterator method uses a ternary with a type cast, which adds minor complexity. Overall, the code is functionally simple but presented in a way that requires extra effort to interpret, reducing readability substantially.
Run 3
The code has a reasonable class structure and method organization, but readability is severely undermined by poor naming. Method names like a(), b(), c(), and d() provide zero clarity of intent, making the code's purpose ambiguous despite the class-level Javadoc. While nesting is minimal and action granularity is acceptable, the single-letter parameter names (a, b, c, d, e) compound the problem. The reading flow is interrupted by having to constantly map cryptic names to their actual meaning. The private helper method d() is called repeatedly but its purpose is unclear without analysis. Code length is appropriate - not overly verbose - but this doesn't compensate for the severe clarity issues. A developer reading this code would need to trace through the logic carefully just to understand basic operations like iteration, size checking, and containment, which should be immediately obvious in a well-named collection class.
Run 1
Code Structure: The class is logically organized into fields, a constructor, set operations, and a lookup helper. Nesting: There is no deep nesting; simple conditionals keep control flow flat. Clarity of intent: Documentation and field names explain the purpose, but single-letter method names and parameters obscure individual operations. The @Override methods also do not match AbstractSet's iterator, size, and contains signatures, making the apparent contract misleading. Code length: The implementation is concise without unnecessary repetition. Action granularity: Statements generally perform one action per line; the ternary expressions remain manageable. Reading flow: The progression from construction to queries to lookup is natural, but repeated cryptic identifiers, especially d as both a parameter and method name, force readers to infer meaning and interrupt comprehension.
Run 2
Code Structure: Fields, constructor, and small methods are logically organized, but the renamed methods obscure the AbstractSet contract; the @Override methods do not match its expected method names. Nesting: Flat control flow and simple conditional expressions make execution easy to follow. Clarity of intent: Class documentation and field names explain the purpose, but single-letter method, parameter, and local-variable names substantially hinder understanding, particularly where d denotes both a parameter and a method. Code length: Concise, with little unnecessary code. Action granularity: Each statement performs a focused action, and the ternary expression is formatted clearly. Reading flow: Conventional class organization supports reading, but cryptic naming forces repeated lookups to understand the lookup, iteration, size, and membership operations.
Run 3
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: Class documentation and field names explain the purpose, but single-letter method, parameter, and local-variable names obscure behavior. The apparent iterator, size, and contains methods are named a, b, and c; their @Override annotations do not match AbstractSet methods, creating confusion and preventing compilation as shown. Code length: Concise, with little unnecessary code. Action granularity: Each statement performs one focused action. Reading flow: Generally natural, but readers must repeatedly trace d() and distinguish it from the parameter named d. Meaningful operation and variable names would substantially improve readability.