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> create() { 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> create(int distinctElements) {
return new LinkedHashMultiset<>(distinctElements); }
/**
* 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> create(
Iterable<? extends E> elements) {
LinkedHashMultiset<E> multiset = create(Multisets.inferDistinctElements(elements));
Iterables.addAll(multiset, elements);
return multiset; }
private LinkedHashMultiset() { super(new LinkedHashMap<E, Count>());
} private LinkedHashMultiset(int distinctElements) {
super(Maps.newLinkedHashMapWithExpectedSize(distinctElements));
} /**
* @serialData the number of distinct elements, the first element, its count, the second element,
* its count, and so on
*/ @GwtIncompatible @J2ktIncompatible
private void writeObject(ObjectOutputStream stream) throws IOException {
stream.defaultWriteObject(); Serialization.writeMultiset(this, stream);
}
@GwtIncompatible
@J2ktIncompatible
private void readObject(ObjectInputStream stream) throws IOException, ClassNotFoundException { stream.defaultReadObject();
int distinctElements = stream.readInt();
setBackingMap(new LinkedHashMap<E, Count>());
Serialization.populateMultiset(this, stream, distinctElements); } @GwtIncompatible @J2ktIncompatible private static final long serialVersionUID = 0;
}
Run 1
The code has severe readability issues primarily due to formatting. Multiple declarations and annotations are placed on the same line as imports (e.g., `@GwtCompatible public final class...`), and closing braces are followed by method definitions on the same line. There is no consistent line break structure, causing visual clutter and making it difficult to identify class boundaries and method signatures. Nesting itself is not excessive, but the lack of vertical separation artificially flattens the hierarchical structure into a dense wall of text. The action granularity criterion is violated repeatedly with multiple statements per line. While the code logically belongs to the Guava collection framework and the intent is documented, the actual code body is difficult to scan quickly due to broken indentation and inline declarations. This formatting would fail typical Java style guides and reduces maintainability despite the underlying logic being straightforward.
Run 2
The code is poorly readable due to severe formatting issues and tangled structure. Multiple imports and Javadoc blocks are compressed onto single lines, making it difficult to parse declarations. Class and method signatures are jammed together, reducing clarity. Documentation is present but rendered hard to read due to line-break inconsistencies. Several methods contain multiple actions per line, violating action granularity and reading flow. Although the overall logic is straightforward and the code isn't deeply nested, the lack of consistent indentation and vertical spacing significantly hampers comprehension. Readability could be dramatically improved by applying standard Java formatting conventions, separating annotations, Javadocs, and statements onto distinct lines.
Run 3
While the code logically represents a class with clear purpose, its readability is severely compromised by formatting. Import statements are merged onto the same line, class and method declarations are concatenated, and opening braces are placed at line ends alongside code. This creates a cramped, tangled visual structure that obscures the logical organization. Although each line generally contains a single action, the compression of structural elements forces the reader to parse dense horizontal blocks. Comments and Javadocs are interleaved awkwardly, disrupting natural reading flow. The underlying logic is straightforward, but the physical layout makes it difficult to scan and maintain.
Run 1
Code Structure: Factories, constructors, and serialization methods are logically ordered, but compressed formatting obscures their boundaries. Nesting: Minimal nesting makes control flow easy to follow. Clarity of intent: Descriptive names and thorough documentation clearly explain behavior, though inherited helpers require external context. Code length: The implementation is concise without substantial redundancy; documentation adds useful context. Action granularity: Several imports, statements, annotations, and declarations share lines, making individual actions harder to distinguish. Reading flow: Inconsistent indentation, inline closing braces, and comments attached to preceding declarations interrupt otherwise natural progression. Overall, the design is readable, but poor formatting noticeably reduces scanability.
Run 2
Code Structure: Factory methods, constructors, and serialization methods are logically grouped, but inconsistent formatting obscures their boundaries. Nesting: Minimal nesting makes the implementation easy to follow. Clarity of intent: Descriptive names and detailed documentation clearly explain behavior, although inherited functionality requires external context. Code length: The implementation is concise, with little redundant logic; documentation adds useful context rather than unnecessary length. Action granularity: Several imports and statements share lines, and declarations are crowded together with annotations, comments, or closing braces, reducing scanability. Reading flow: The overall order is natural, but inconsistent indentation, misplaced line breaks, and compressed method boundaries repeatedly interrupt reading.
Run 3
Code Structure: Factory methods, constructors, and serialization methods are logically grouped, but inconsistent formatting obscures their boundaries. Nesting: Very shallow, with no complex conditionals or loops. Clarity of intent: Descriptive names and thorough documentation explain the multiset's behavior and method purposes. Code length: The implementation is concise, with little unnecessary code; documentation is proportionate. Action granularity: Several imports, declarations, annotations, and statements share lines, making individual actions harder to scan. Reading flow: Irregular indentation, closing braces attached to statements, and comments immediately following declarations disrupt otherwise natural top-to-bottom organization. Overall, the simple design is understandable, but formatting significantly reduces readability.