Source code
package com.google.common.graph;
import java.util.Optional;
import java.util.Set; import org.jspecify.annotations.Nullable;
/**
* A class to allow {@link Network} implementations to be backed by a provided delegate. This is not
* currently planned to be released as a general-purpose forwarding class.
*
* @author James Sexton
* @author Joshua O'Madadhain
*/ abstract class ForwardingNetwork<N, E> extends AbstractNetwork<N, E> { abstract Network<N, E> delegate();
@Override public Set<N> nodes() {
return delegate().nodes();
} @Override
public Set<E> edges() { return delegate().edges();
} @Override
public boolean isDirected() {
return delegate().isDirected();
}
@Override public boolean allowsParallelEdges() {
return delegate().allowsParallelEdges();
} @Override public boolean allowsSelfLoops() {
return delegate().allowsSelfLoops();
} @Override public ElementOrder<N> nodeOrder() { return delegate().nodeOrder(); } @Override
public ElementOrder<E> edgeOrder() { return delegate().edgeOrder(); }
@Override public Set<N> adjacentNodes(N node) {
return delegate().adjacentNodes(node); }
@Override public Set<N> predecessors(N node) {
return delegate().predecessors(node);
} @Override
public Set<N> successors(N node) {
return delegate().successors(node);
}
@Override public Set<E> incidentEdges(N node) {
return delegate().incidentEdges(node); } @Override
public Set<E> inEdges(N node) {
return delegate().inEdges(node);
} @Override
public Set<E> outEdges(N node) {
return delegate().outEdges(node); }
@Override
public EndpointPair<N> incidentNodes(E edge) {
return delegate().incidentNodes(edge);
} @Override
public Set<E> adjacentEdges(E edge) {
return delegate().adjacentEdges(edge);
}
@Override
public int degree(N node) { return delegate().degree(node); }
@Override
public int inDegree(N node) {
return delegate().inDegree(node);
} @Override public int outDegree(N node) {
return delegate().outDegree(node);
}
@Override
public Set<E> edgesConnecting(N nodeU, N nodeV) {
return delegate().edgesConnecting(nodeU, nodeV);
}
@Override
public Set<E> edgesConnecting(EndpointPair<N> endpoints) { return delegate().edgesConnecting(endpoints);
} @Override public Optional<E> edgeConnecting(N nodeU, N nodeV) {
return delegate().edgeConnecting(nodeU, nodeV);
} @Override
public Optional<E> edgeConnecting(EndpointPair<N> endpoints) {
return delegate().edgeConnecting(endpoints); } @Override public @Nullable E edgeConnectingOrNull(N nodeU, N nodeV) {
return delegate().edgeConnectingOrNull(nodeU, nodeV);
}
@Override
public @Nullable E edgeConnectingOrNull(EndpointPair<N> endpoints) {
return delegate().edgeConnectingOrNull(endpoints); }
@Override
public boolean hasEdgeConnecting(N nodeU, N nodeV) { return delegate().hasEdgeConnecting(nodeU, nodeV); }
@Override public boolean hasEdgeConnecting(EndpointPair<N> endpoints) { return delegate().hasEdgeConnecting(endpoints); }
}
Run 1
The code has a clear purpose but suffers from severe formatting inconsistencies that significantly hurt readability. Structurally, the class hierarchy is clear with the delegate pattern, but the physical layout is tangled. Inconsistent line breaks cause multiple methods to appear on single lines or in cramped blocks (e.g., three methods packed into one visual line). Nesting is flat, which is good, and intent is mostly clear since each method simply delegates. However, the erratic placement of annotations, braces, and method signatures disrupts the reading flow and action granularity. Action granularity is high (one action per method) but visually violated by cramming multiple signatures on one line. Code length is not excessive, but it is disorganized. Overall, the logic is simple and would be readable if formatted consistently, but as written it requires extra effort to parse. It is readable with difficulty, hence a moderate-to-low score.
Run 2
The code is a simple delegation pattern but suffers from severe formatting inconsistencies. Multiple methods are crammed onto single lines, and some methods start on the same line as the previous method's closing brace, breaking logical separation. The import statements are also inconsistent (multiple imports on one line). While the intent is clear—forwarding Network calls to a delegate—the erratic whitespace and method arrangement make it visually noisy and hard to scan. The nesting is flat and logic is trivial, but the poor physical layout undermines readability. Applying consistent formatting (one method per block, proper line breaks) would raise this to ~15+ without changing any logic.
Run 3
The code has serious formatting and structure issues that hurt readability. While each method is a simple one-line delegation, the inconsistent placement of @Override annotations, methods, and braces on the same line makes the code disorganized and hard to scan. Several methods are crammed together on single lines (e.g., `} @Override public Set<E> edges() { return delegate().edges(); }`), violating the 'one action per line' and 'reading flow' criteria. The import statements are also compressed onto one line. However, the underlying intent is clear—each method delegates to another Network—and the method names are descriptive. The class-level Javadoc is helpful. Overall, the tangled formatting significantly undermines readability despite the simple logic.
Run 1
Code Structure: Methods are logically grouped within a straightforward forwarding class, but inconsistent formatting obscures their boundaries. Nesting: Minimal nesting makes each method easy to understand. Clarity of intent: Descriptive names, documentation, and uniform delegate calls clearly communicate the purpose. Code length: The implementation is appropriately concise; repetition is justified by the forwarding interface. Action granularity: Each method performs one action, but imports, annotations, declarations, and closing braces frequently share lines, reducing visual separation. Reading flow: The predictable delegation pattern helps comprehension, while irregular line breaks and compressed method transitions hinder scanning. Consistent formatting would substantially improve readability.
Run 2
Code Structure: Methods are logically grouped around network properties, adjacency, degrees, and edge connections, but inconsistent formatting obscures boundaries. Nesting: Very shallow; each method simply forwards a call, with no nested control flow. Clarity of intent: The class documentation, descriptive method names, and consistent delegate() pattern clearly communicate its forwarding purpose. Code length: Appropriately concise for the required overrides; repetition is inherent to this design. Action granularity: Each method performs one action, but multiple imports, declarations, annotations, and braces share lines, reducing visual separation. Reading flow: The repetitive forwarding pattern is easy to follow, but irregular line breaks and crowded method transitions disrupt scanning. Consistent formatting and separate lines for imports and method boundaries would substantially improve readability.
Run 3
Code Structure: Methods are logically grouped by network properties, adjacency, degrees, and edge queries, but inconsistent formatting obscures boundaries. Nesting: Excellent; methods contain simple returns without nested control flow. Clarity of intent: Strong; descriptive names, documentation, and consistent delegation make the forwarding purpose obvious. Code length: Appropriate for implementing the interface; repetition is necessary rather than unnecessary verbosity. Action granularity: Each method performs one action, but multiple imports, declarations, annotations, and braces share lines, reducing visual separation. Reading flow: Predictable method ordering helps, while irregular line breaks and cramped transitions interrupt scanning. Overall, the code is semantically straightforward but needs consistent formatting to become highly readable.