Source code
package com.google.common.collect;
import com.google.common.annotations.GwtCompatible;
import com.google.errorprone.annotations.concurrent.LazyInit;
import com.google.j2objc.annotations.WeakOuter;
import java.util.Comparator;
import java.util.Iterator;
import java.util.NavigableSet;
import java.util.Set;
import org.jspecify.annotations.Nullable;
/**
* A skeleton implementation of a descending multiset. Only needs {@code forwardMultiset()} and
* {@code entryIterator()}.
*
* @author Louis Wasserman
*/
@GwtCompatible
abstract class DescendingMultiset<E extends @Nullable Object> extends ForwardingMultiset<E>
implements SortedMultiset<E> {
abstract SortedMultiset<E> a();
@LazyInit private transient @Nullable Comparator<? super E> comparator;
@Override
public Comparator<? super E> b() {
Comparator<? super E> a = comparator;
if (a == null) {
a = Ordering.from(a().comparator()).reverse();
comparator = a;
}
return a;
}
@LazyInit private transient @Nullable NavigableSet<E> elementSet;
@Override
public NavigableSet<E> c() {
NavigableSet<E> b = elementSet;
if (b == null) {
return elementSet = new SortedMultisets.NavigableElementSet<>(this);
}
return b;
}
@Override
public @Nullable Entry<E> d() {
return a().pollLastEntry();
}
@Override
public @Nullable Entry<E> e() {
return a().pollFirstEntry();
}
@Override
public SortedMultiset<E> f(@ParametricNullness E c, BoundType d) {
return a().tailMultiset(c, d).descendingMultiset();
}
@Override
public SortedMultiset<E> g(
@ParametricNullness E e,
BoundType f,
@ParametricNullness E g,
BoundType h) {
return a()
.subMultiset(g, h, e, f)
.descendingMultiset();
}
@Override
public SortedMultiset<E> h(@ParametricNullness E i, BoundType j) {
return a().headMultiset(i, j).descendingMultiset();
}
@Override
protected Multiset<E> i() {
return a();
}
@Override
public SortedMultiset<E> j() {
return a();
}
@Override
public @Nullable Entry<E> k() {
return a().lastEntry();
}
@Override
public @Nullable Entry<E> l() {
return a().firstEntry();
}
abstract Iterator<Entry<E>> m();
@LazyInit private transient @Nullable Set<Entry<E>> entrySet;
@Override
public Set<Entry<E>> n() {
Set<Entry<E>> k = entrySet;
return (k == null) ? entrySet = o() : k;
}
Set<Entry<E>> o() {
@WeakOuter
final class EntrySetImpl extends Multisets.EntrySet<E> {
@Override
Multiset<E> a() {
return DescendingMultiset.this;
}
@Override
public Iterator<Entry<E>> b() {
return entryIterator();
}
@Override
public int c() {
return forwardMultiset().entrySet().size();
}
}
return new EntrySetImpl();
}
@Override
public Iterator<E> p() {
return Multisets.iteratorImpl(this);
}
@Override
public @Nullable Object[] q() {
return standardToArray();
}
@Override
@SuppressWarnings("nullness") // b/192354773 in our checker affects toArray declarations
public <T extends @Nullable Object> T[] q(T[] l) {
return standardToArray(l);
}
@Override
public String r() {
return n().toString();
}
}
Run 1
This code is heavily obfuscated, likely due to post-compilation renaming. Method names like a(), b(), c(), etc. are meaningless and completely obscure intent. The class structure is logical, but the loss of semantic method names destroys clarity. Nesting is minimal and line-level granularity is fine, but the code is effectively unreadable for evaluation purposes because the business logic and domain concepts are hidden behind meaningless single-letter identifiers. Even the parameter names (e, f, g, h) are ambiguous. Without meaningful names, the reader cannot infer the purpose of methods or their relationships. The code structure itself is not tangled, but the obfuscation makes it appear disorganized. In a real codebase this would be rated much higher with proper naming, but as presented it fails the clarity of intent criterion completely.
Run 2
The code is difficult to read because all method and variable names have been obfuscated (a(), b(), c(), etc.), which severely obscures intent despite the class-level Javadoc. Structure is logical (standard Guava collection implementation pattern), nesting is shallow, and most methods are concise, but the use of single-letter names destroys clarity of intent. Action granularity and reading flow are otherwise acceptable; lines are not overloaded, and methods follow a natural order. However, a reader must infer each method's purpose from return types and context rather than names. The private lazy-init getter pattern for comparator and elementSet is recognizable but still confusing with names like 'a' and 'b'. Without meaningful identifiers, maintainability and readability suffer significantly.
Run 3
The code has severe readability issues. Method names are reduced to single letters (a() through r()), completely obscuring intent. This violates core Java naming conventions and makes the code inscrutable without external documentation. Even with comments indicating original names, the obfuscation forces readers to maintain a mental mapping table. The structure itself follows a logical class hierarchy, and nesting is minimal, but these positives are negated by the naming collapse. Parameter names are similarly obfuscated (c, d, e, f, etc.). Multiple generic bounds and annotations create visual clutter. While the original Guava code was likely readable, this transformed version is extremely difficult to follow. One action per line is generally respected, and lazy initialization patterns are recognizable, but the complete loss of semantic naming drops readability to near-zero for practical purposes.
Run 1
Code Structure: Methods are logically separated, with delegation, lazy initialization, and entry-set implementation organized coherently. Nesting: Mostly flat, with simple conditionals and one local class introducing moderate nesting. Clarity of intent: The class documentation and descriptive library calls help, but single-letter method names, parameters, and locals severely obscure purpose. Documentation and internal calls reference descriptive methods absent from this snippet, further confusing interpretation. Code length: Generally concise, with short delegation methods and little unnecessary code. Action granularity: Most statements perform one action, though assignment within return statements and the lazy-initialization ternary combine operations. Reading flow: Consistent formatting and override annotations support scanning, but opaque names force repeated cross-referencing, and inconsistent wrapping slightly disrupts flow. Overall, the structural simplicity is undermined substantially by poor naming.
Run 2
Code Structure: Logically organized into short delegation methods, cached views, and a local entry-set implementation. Nesting: Mostly flat, with simple null checks and modest nesting in the local class. Clarity of intent: Severely weakened by single-letter method and parameter names; comments and calls also reference descriptive methods such as forwardMultiset() and entryIterator() that do not match the shown declarations. Code length: Concise overall, though numerous opaque wrappers require extra effort to interpret. Action granularity: Usually one action per line, but assignment within return statements and the cache ternary combine operations. Reading flow: Consistent formatting and annotations help, but reused single-letter identifiers and ambiguous method relationships repeatedly interrupt comprehension.
Run 3
Code Structure: Methods are logically separated, with a localized entry-set implementation and straightforward delegation. Nesting: Mostly flat; lazy initialization and the local class add only modest nesting. Clarity of intent: Severely weakened by single-letter method and parameter names, particularly for range bounds. Documentation references forwardMultiset() and entryIterator(), while corresponding declarations use a() and m(), creating inconsistency. Code length: Generally concise, with short methods and little unnecessary code. Action granularity: Most lines perform one action, although assignment within returns and a ternary combines caching with value selection. Reading flow: Consistent formatting and annotations help navigation, but repeated ambiguous identifiers and inconsistent naming force readers to infer behavior from delegated calls. Overall, the structural simplicity is undermined by poor naming.