Source code
package com.google.common.collect;
import com.google.common.annotations.GwtCompatible;
import com.google.common.annotations.GwtIncompatible;
import com.google.common.annotations.J2ktIncompatible;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.util.LinkedHashMap;
import org.jspecify.annotations.Nullable;
/**
* A {@code Multiset} implementation with predictable iteration order. Its iterator orders elements
* according to when the first occurrence of the element was added. When the multiset contains
* multiple instances of an element, those instances are consecutive in the iteration order. If all
* occurrences of an element are removed, after which that element is added to the multiset, the
* element will appear at the end of the iteration.
*
* <p>See the Guava User Guide article on <a href=
* "https://github.com/google/guava/wiki/NewCollectionTypesExplained#multiset">{@code Multiset}</a>.
*
* @author Kevin Bourrillion
* @author Jared Levy
* @since 2.0
*/
@GwtCompatible
public final class LinkedHashMultiset<E extends @Nullable Object>
extends AbstractMapBasedMultiset<E> {
/** Creates a new, empty {@code LinkedHashMultiset} using the default initial capacity. */
public static <E extends @Nullable Object> LinkedHashMultiset<E> a() {
return new LinkedHashMultiset<>();
}
/**
* Creates a new, empty {@code LinkedHashMultiset} with the specified expected number of distinct
* elements.
*
* @param distinctElements the expected number of distinct elements
* @throws IllegalArgumentException if {@code distinctElements} is negative
*/
public static <E extends @Nullable Object> LinkedHashMultiset<E> a(int a) {
return new LinkedHashMultiset<>(a);
}
/**
* Creates a new {@code LinkedHashMultiset} containing the specified elements.
*
* <p>This implementation is highly efficient when {@code elements} is itself a {@link Multiset}.
*
* @param elements the elements that the multiset should contain
*/
public static <E extends @Nullable Object> LinkedHashMultiset<E> a(
Iterable<? extends E> b) {
LinkedHashMultiset<E> c = a(Multisets.inferDistinctElements(b));
Iterables.addAll(c, b);
return c;
}
private LinkedHashMultiset() {
super(new LinkedHashMap<E, Count>());
}
private LinkedHashMultiset(int d) {
super(Maps.newLinkedHashMapWithExpectedSize(d));
}
/**
* @serialData the number of distinct elements, the first element, its count, the second element,
* its count, and so on
*/
@GwtIncompatible
@J2ktIncompatible
private void b(ObjectOutputStream e) throws IOException {
e.defaultWriteObject();
Serialization.writeMultiset(this, e);
}
@GwtIncompatible
@J2ktIncompatible
private void c(ObjectInputStream f) throws IOException, ClassNotFoundException {
f.defaultReadObject();
int g = f.readInt();
setBackingMap(new LinkedHashMap<E, Count>());
Serialization.populateMultiset(this, f, g);
}
@GwtIncompatible @J2ktIncompatible private static final long serialVersionUID = 0;
}
Run 1
The code is poorly readable due to deliberate obfuscation. Method names like 'a' and single-letter parameters ('a', 'b', 'c', 'd', 'e', 'f', 'g') violate clarity of intent, making the purpose of each method and parameter unclear. The factory methods are heavily overloaded with cryptic names, and variable names like 'b' and 'c' obscure meaning. The serialization methods 'b' and 'c' are especially unclear. Indentation before these methods is inconsistent, harming code structure and reading flow. Nesting is acceptable, and action granularity is mostly one action per line, but the intentional name obfuscation dominates the readability assessment. The comments remain descriptive, but the implementation does not reflect clear naming practices expected in production code.
Run 2
This code has severe readability issues. The method names 'a', 'b', and 'c' are meaningless and provide no clarity of intent. Parameter names like 'a', 'b', 'c', 'd', 'e', 'f', 'g' are equally unhelpful. The class represents LinkedHashMultiset in Guava, but the obfuscated naming destroys understanding. While the code structure is logically organized with constructors and factory methods grouped together, and nesting is minimal, the single-letter identifiers make it nearly unreadable. Code length is concise, but at the cost of clarity. The Javadoc is well-written but doesn't compensate for the cryptic method names. Action granularity is generally one action per line, and reading flow suffers greatly from the ambiguous naming. This appears to be deliberately obfuscated code, perhaps as a test of reading comprehension, rather than production-quality code.
Run 3
The code is well-structured with clear organization and proper documentation. Class-level Javadoc explains the purpose and behavior clearly. The method names are extremely poor—single-letter identifiers like 'a', 'b', 'c', 'd', 'e', 'f', 'g' obscure intent, violating clarity and readability standards. The code is relatively flat with minimal nesting, and action granularity is acceptable with one operation per line. Method contract documentation exists but references parameter names that don't match the actual obfuscated names. The serialization methods are notably missing visibility modifiers and have misaligned indentation, disrupting reading flow. Import ordering and class annotation placement are clean. Overall structure is logical and concise, but naming choices severely undermine readability.
Run 1
Code Structure: Factories, constructors, and serialization helpers are logically grouped, with small, focused methods. Nesting: The code is flat, with no nested control flow. Clarity of intent: Class documentation and library calls explain the overall purpose, but single-letter method and variable names obscure individual roles. Documentation parameter names also do not match the actual parameters. Code length: The implementation is concise without unnecessary repetition; documentation adds useful context. Action granularity: Most lines perform one action, although the final line combines annotations and a field declaration. Reading flow: The ordering is natural, but inconsistent indentation, compressed annotations, and opaque overloaded names interrupt scanning. Overall, strong structural simplicity is undermined by poor naming and minor formatting issues.
Run 2
Code Structure: Factory methods, constructors, and serialization helpers are logically grouped. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Class documentation explains behavior well, but single-letter method and variable names obscure purpose; parameter documentation also mismatches actual names. Code length: The implementation is concise, with short methods and little redundancy. Action granularity: Most lines contain one action, although the final line compresses annotations and a field declaration. Reading flow: Organization is natural, but inconsistent indentation, crowded annotations, and ambiguous overloaded names interrupt readability. Descriptive names and consistent formatting would substantially improve the score.
Run 3
Code Structure: Factories, constructors, and serialization-related methods are logically grouped, with small, focused methods. Nesting: Essentially flat, making control flow easy to follow. Clarity of intent: Detailed documentation and recognizable library calls explain the overall purpose, but single-letter method and variable names obscure individual roles. Documentation parameter names also disagree with actual signatures. Renamed serialization methods hide their intended lifecycle roles. Code length: Concise, with little unnecessary implementation code; documentation is useful rather than excessive. Action granularity: Statements generally perform one action per line. Reading flow: Organization is natural, but inconsistent indentation, compressed annotations on the final field, and ambiguous overloaded names interrupt readability.