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> a();
@Override
public Set<N> b() {
return a().nodes();
}
@Override
public Set<E> c() {
return a().edges();
}
@Override
public boolean d() {
return a().isDirected();
}
@Override
public boolean e() {
return a().allowsParallelEdges();
}
@Override
public boolean f() {
return a().allowsSelfLoops();
}
@Override
public ElementOrder<N> g() {
return a().nodeOrder();
}
@Override
public ElementOrder<E> h() {
return a().edgeOrder();
}
@Override
public Set<N> i(N a) {
return a().adjacentNodes(a);
}
@Override
public Set<N> j(N b) {
return a().predecessors(b);
}
@Override
public Set<N> k(N c) {
return a().successors(c);
}
@Override
public Set<E> l(N d) {
return a().incidentEdges(d);
}
@Override
public Set<E> m(N e) {
return a().inEdges(e);
}
@Override
public Set<E> n(N f) {
return a().outEdges(f);
}
@Override
public EndpointPair<N> o(E g) {
return a().incidentNodes(g);
}
@Override
public Set<E> p(E h) {
return a().adjacentEdges(h);
}
@Override
public int q(N i) {
return a().degree(i);
}
@Override
public int r(N j) {
return a().inDegree(j);
}
@Override
public int s(N k) {
return a().outDegree(k);
}
@Override
public Set<E> t(N l, N m) {
return a().edgesConnecting(l, m);
}
@Override
public Set<E> t(EndpointPair<N> n) {
return a().edgesConnecting(n);
}
@Override
public Optional<E> u(N o, N p) {
return a().edgeConnecting(o, p);
}
@Override
public Optional<E> u(EndpointPair<N> q) {
return a().edgeConnecting(q);
}
@Override
public @Nullable E v(N r, N s) {
return a().edgeConnectingOrNull(r, s);
}
@Override
public @Nullable E v(EndpointPair<N> t) {
return a().edgeConnectingOrNull(t);
}
@Override
public boolean w(N u, N v) {
return a().hasEdgeConnecting(u, v);
}
@Override
public boolean w(EndpointPair<N> w) {
return a().hasEdgeConnecting(w);
}
}
Run 1
This code is extremely difficult to read due to deliberate obfuscation. Method names (a, b, c, etc.) and parameter names (a, b, c...) provide zero semantic meaning, completely obscuring intent. The single-letter names force the reader to constantly cross-reference the Network interface to understand each method's purpose. While the structure is technically flat (good), the clarity of intent, reading flow, and general readability are severely compromised. The code is concise, but at the cost of being useless for maintenance or review. Comment and package/import sections are fine, but they cannot compensate for the cryptic identifiers.
Run 2
The code has flat, consistent method delegation, and each method performs one action, which aids predictability. However, readability is severely undermined by meaningless single-letter method names (a through w) and generic parameter names (a, b, c...). Intent is completely ambiguous without looking up each abbreviation, destroying the natural reading flow. The class documentation explains the design but cannot compensate for opaque naming. There is also parameter shadowing in some methods (e.g., i(N a) calls a().adjacentNodes(a)), which is confusing. Overall structure and length are fine, but clarity of intent and reading flow are critically weak.
Run 3
The code structure is logical but severely undermined by obfuscated naming (single-letter method names, vague delegate method 'a()'). Nesting is flat, which is good, but clarity of intent is poor because the method names convey no meaning about their operations. Code length is concise but at the cost of readability. Action granularity is appropriate—one action per line. Reading flow is natural in terms of formatting and order, but the cryptic identifiers disrupt comprehension. The class appears to be a forwarding wrapper, but understanding each method's purpose requires cross-referencing the delegate interface, defeating the purpose of readable code.
Run 1
Code Structure: Logically organized as a forwarding class, with related methods and overloads grouped together. Nesting: Flat, with no conditionals, loops, or nested control flow. Clarity of intent: The documentation and descriptive delegate calls explain the overall purpose, but single-letter method and parameter names obscure individual operations and argument roles. Code length: Each method is concise; the overall length largely reflects necessary forwarding boilerplate rather than unnecessary complexity. Action granularity: Each method contains one straightforward return statement, making operations easy to isolate. Reading flow: Consistent formatting and repeated delegation patterns support predictable scanning, but opaque names force readers to inspect method bodies to understand the API.
Run 2
Code Structure: Methods are consistently organized as straightforward delegate wrappers, with related overloads grouped together. Nesting: There is no control-flow nesting, making each method easy to follow. Clarity of intent: The class documentation and descriptive delegate calls explain the forwarding purpose, but single-letter method and parameter names obscure the public operations and argument roles. Using a for both the delegate accessor and a parameter adds visual confusion. Code length: Each method is concise; the overall length comes from necessary forwarding boilerplate rather than complex logic. Action granularity: Each method performs one return operation on its own line. Reading flow: Consistent formatting and a predictable forwarding pattern support scanning, but readers must inspect method bodies to discover what the cryptically named methods do.
Run 3
Code Structure: Well-organized forwarding class with consistent method layout and related overloads grouped together. Nesting: Completely flat; each method contains a single return statement. Clarity of intent: The class documentation and descriptive delegate calls explain the forwarding purpose, but single-letter method and parameter names obscure the public operations and argument roles. The repeated a() accessor is particularly uninformative. Code length: Individual methods are concise; the overall length reflects necessary forwarding boilerplate rather than unnecessarily complex logic. Action granularity: Each statement performs one straightforward delegation, with no bundled unrelated actions. Reading flow: Consistent formatting and predictable delegation make scanning easy, but alphabetical method names force readers to inspect implementations to understand each operation. Descriptive names would substantially improve readability.