Source code
package com.google.common.graph;
import com.google.common.collect.ImmutableSet;
import java.util.AbstractSet;
import java.util.Set;
import org.jspecify.annotations.Nullable;
/**
* Abstract base class for an incident edges set that allows different implementations of {@link
* AbstractSet#iterator()}.
*/
abstract class IncidentEdgeSet<N> extends AbstractSet<EndpointPair<N>> {
final N node;
final ArchetypeGraph<N> graph;
final EdgeType edgeType;
enum EdgeType {
INCOMING, // incoming incident edges only
OUTGOING, // outgoing incident edges only
BOTH // both incoming and outgoing incident edges
}
IncidentEdgeSet(ArchetypeGraph<N> a, N b, EdgeType c) {
this.graph = a;
this.node = b;
this.edgeType = c;
}
@Override
public boolean a(@Nullable Object d) {
throw new UnsupportedOperationException();
}
@Override
public int b() {
if (graph.isDirected()) {
return d(node).size()
+ e(node).size()
- (edgeType == EdgeType.BOTH && d(node).contains(node) ? 1 : 0);
} else {
return graph.adjacentNodes(node).size();
}
}
@Override
public boolean c(@Nullable Object e) {
if (!(e instanceof EndpointPair)) {
return false;
}
EndpointPair<?> f = (EndpointPair<?>) e;
if (graph.isDirected() != f.isOrdered()) {
return false;
}
if (graph.isDirected()) {
Object g = f.source();
Object h = f.target();
return (node.equals(g) && e(node).contains(h))
|| (node.equals(h) && d(node).contains(g));
} else {
Set<N> i = graph.adjacentNodes(node);
Object j = f.nodeU();
Object k = f.nodeV();
return (node.equals(k) && i.contains(j))
|| (node.equals(j) && i.contains(k));
}
}
/**
* Returns the predecessors of the given node, or an empty set if this set does not represent
* incoming edges.
*/
private Set<N> d(N l) {
if (edgeType == EdgeType.INCOMING || edgeType == EdgeType.BOTH) {
return graph.predecessors(l);
} else {
return ImmutableSet.of();
}
}
/**
* Returns the successors of the given node, or an empty set if this set does not represent
* outgoing edges.
*/
private Set<N> e(N m) {
if (edgeType == EdgeType.OUTGOING || edgeType == EdgeType.BOTH) {
return graph.successors(m);
} else {
return ImmutableSet.of();
}
}
}
Run 1
The code has significant readability problems. Method names are single letters (a, b, c, d, e), which obscure their purpose. Parameter names (a, b, c, d, e, f, g, h, i, j, k, l, m) provide no semantic meaning. The boolean logic in method b() requires careful parsing to understand the directed edge counting logic. However, the structure is reasonably organized with helper methods for predecessors/successors, and nesting depth is moderate. The class-level Javadoc and enum provide some context, but the private helper methods d() and e() have misleading names that don't reflect their actual behavior. The mathematical expression in b() performs multiple operations on one line (size additions and conditional subtraction), reducing clarity. While the code is syntactically valid and follows some conventions, the naming choices alone make it difficult to read and maintain.
Run 2
The code structure is logical and the abstraction is clear, but readability is severely degraded by meaningless method and parameter names (a, b, c, d, e, f, g, h, i, j, k, l, m). This obscures intent and forces readers to infer behavior rather than understand it directly. Nesting is somewhat flat, and method length is reasonable, but the loss of naming clarity dominates. Action granularity is mixed: some lines contain multiple logical checks. Reading flow suffers due to the disconnection between Javadoc and the obfuscated method names. Overall, the code requires significant mental effort to parse and maintain.
Run 3
The code is largely unreadable due to obfuscated naming conventions (single-letter method and variable names like a, b, c, d, e, f, g, h, i, j, k, l, m), which severely undermines clarity of intent and reading flow. While the structure is logically organized and nesting is relatively flat, the use of cryptic identifiers makes it impossible to understand behavior without extensive reverse engineering. Action granularity is mostly one action per line, and code length is concise, but these are outweighed by the severe clarity failure. The presence of Javadoc on helper methods is good, but it doesn't compensate for the overall unreadability caused by poor naming and ambiguous parameter types.
Run 1
Code Structure: Fields, enum, constructor, and helper methods are logically organized with good separation of responsibilities. Nesting: Shallow conditionals and early returns keep complexity manageable. Clarity of intent: Descriptive class and field names, enum values, and helper documentation help, but single-letter method names and variables substantially obscure purpose; the renamed @Override methods also conflict with expected AbstractSet method names. Code length: Compact overall, with little unnecessary code, though repeated directedness checks add minor redundancy. Action granularity: Most statements perform one action, but compound membership expressions and the size calculation require extra interpretation. Reading flow: Formatting and method grouping are consistent, yet opaque identifiers force readers to trace helpers and infer operations rather than understand them directly.
Run 2
Code Structure: Fields, enum, constructor, and focused methods are logically organized. Nesting: Shallow conditionals and early returns keep complexity manageable. Clarity of intent: The class documentation, enum, and graph operations convey the overall purpose, but single-letter method and variable names severely obscure individual roles; methods marked @Override also do not match AbstractSet method names. Code length: Compact and largely free of unnecessary repetition, though explicit else branches could be simplified. Action granularity: Most statements perform one action, but compound membership tests and the size calculation require extra interpretation. Reading flow: Consistent formatting and helper documentation support navigation, while cryptic identifiers, especially e as both a parameter and method name, interrupt natural reading.
Run 3
Code Structure: The class is logically organized into fields, an enum, a constructor, public operations, and private helpers. Nesting: Shallow conditionals and early returns keep complexity manageable. Clarity of intent: Descriptive class and field names, enum values, and helper documentation help, but single-letter method and variable names obscure operations and graph roles. The apparent AbstractSet overrides named a, b, and c further confuse the intended API. Code length: Compact and mostly free of unnecessary repetition. Action granularity: Statements generally perform one action per line, although compound membership expressions and the size calculation require extra interpretation. Reading flow: Formatting and method grouping are consistent, but readers must repeatedly map cryptic identifiers to their meanings, interrupting otherwise natural flow.